Configuration updates in a Kubernetes cluster

[asymmetric]

Kubernetes is responsible for delivering configuration updates to pods in the form of Secrets/ConfigMaps.

The Supervisor will watch for the file, which location you pass in as an argument to a flag when starting the service (for example: ... --config-file <dir>/<filename>). If a change was made to the file, the supervisor will react in the same way as it does now with receiving a config update over gossip. We would possibly need to disable config update gossip part of the supervisor.

As it needs to contain service group, version and the actual configuration data we are open for suggestions as to what format we want this file in. Maybe we can go with toml format as this is already common in Habitat.

The solution does not depend on Kubernetes at all, it can be for use cases outside of the Kubernetes world.

We are open to any ideas and suggestions on the details of this implementation.

[adamhjk]

I think we should consider:

1. I think we just need to add the functionality to user.toml to automatically reload on changes. That way we don't add another layer of complexity into habitat, and k8s users (and anyone else who wants to drive configuration externally) can do so easily.

2. The format is absolutely toml, as that's the language of configuration in habitat, and we don't want to introduce another one.

3. I think we can delay needing to disable receipt of configuration through gossip until we have a user that requests it.

Great progress.