..

Day 2: Neutron

Today was mostly spent figuring out why my data in InfluxDB wasn’t persistent across a container reboot - turns out, the folder I had mapped as a volume had incorrect permissions so InfluxDB was just storing data in memory. Eventually the container crashed :)

Fixed that issue.

I also have been thinking more about the authentication mechanism for the Neutrinos. I think it makes the most sense for the Neutrons to have an individual key that has access to the default bucket, while also being able to use a customer API key when they’re writing to that customer’s bucket. So I will need to write logic to allow the Neutrinos to pull the customer token from the database when they’re assigned the customer. This should be stored in memory, not on disk, so it’ll be pulled when the script starts and stored in a variable.

Logic will need to be added to generate an API key for each customer and store in the database as well. This should be a quick modification of the function generateNeutrinoToken() to become generateToken(tokenDescription) and then it’ll need to be provided with the tokenDescription as part of the process. This way I can generate Neutrino or Customer tokens in the same function.

Lots of time will need to be spent on error handling and testing.

What happens when:

  • InfluxDB is down/unavailable => Points should be cached and then batch processed once available
  • CouchDB is down/unavailable => Unable to get configuration details, stick with details the Neutrino has (default/default)
  • Errors returned from InfluxDB API, called by Neutron’s API

CouchDB needs to be renamed from neutron to something else. Neutron is what my API should be called, while CouchDB is just a configuration store. Maybe “quark”.

These are my thoughts today, I might spend some more time on this late this evening.

/wes