Open Stack

Excerpts from Emilien Macchi's message of 2017-06-06 18:08:36 +0200:
> Following-up the session that we had in Boston:
> https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management
> 
> Here's an update on where we are and what is being done.
> 
> 
> == Machine Readable Sample Config
> 
> Ben's spec has been merged: https://review.openstack.org/#/c/440835/
> And also the code which implements it: https://review.openstack.org/#/c/451081/
> He's now working on the documentation on how to use the feature.
> 
> $ oslo-config-generator --namespace keystone --formal yaml > keystone.yaml
> 
> Here's an example of the output for Keystone config: https://clbin.com/EAfFM
> This feature was asked at the PTG, and it's already done!
> 
> 
> == Pluggable drivers for oslo.config
> 
> Doug's spec has been well written and the feedback from Summit and the
> review was taken in account: https://review.openstack.org/#/c/454897/
> It's now paused because we think we could use confd (with etcd driver)
> to generate configuration files.
> 
> Imagine the work done by Ben in Machine Readable Sample Config, that
> would allow us to generate Confd templates for all services (Keystone,
> Nova, etc) via a tool provided in oslo.config with all the options
> available for a namespace.
> We could have packaging builds (e.g. RDO distgit) using the tooling
> when building packages so we could ship confd templates in addition of
> ini configuration files.
> When services would start (e.g. in containers), confd would generate
> configuration files from the templates that is part of the container,
> and read the values from etcd.
> 
> The benefit of doing this, is that a very little work is required in
> oslo.config to make this happen (only a tool to generate confd
> templates). It could be a first iteration.
> Another benefit is that confd will generate a configuration file when
> the application will start. So if etcd is down *after* the app
> startup, it shouldn't break the service restart if we don't ask confd
> to re-generate the config. It's good for operators who were concerned
> about the fact the infrastructure would rely on etcd. In that case, we
> would only need etcd at the initial deployment (and during lifecycle
> actions like upgrades, etc).

Another benefit is that confd can be used to monitor changes to
configuration and update the file that it writes. When changes are
found, it can also send a signal to the application, which ties in
nicely to the existing mutable configuration behavior already in
oslo.service and oslo.config. So, we get fast updates for mutable
options in services that support them, without building a complicated
driver to talk to etcd ourselves.

> The downside is that in the case of containers, they would still have
> a configuration file within the container, and the whole goal of this
> feature was to externalize configuration data and stop having
> configuration files.

The OpenStack component's configuration file won't need to be added
to the container in advance, though. Only the confd settings need
to be included, and those are application-specific but not container
instance-specific.

> 
> 
> == What's next
> 
> I see 2 short-term actions that we can work on:
> 
> 1) Decide if whether or not confd solution would be acceptable for a
> start. I'm asking Kolla, TripleO, Helm, Ansible projects if they would
> be willing to use this feature. I'm also asking operators to give
> feedback on it.
> 
> 2) Investigate how to expose parameters generated by Ben's work on
> Machine Readable Sample Config to the users (without having to
> manually maintain all options) - I think this has to be solved on the
> installers side, but I might be wrong; and also investigate how to
> populate parameters data into etcd. This tool could be provided by
> oslo.config probably.

What sort of tool are you thinking of here?  We could add a tool
to oslo.config to upload the settings, but I would expect deployment
tools to work more directly with etcd and not want to run a separate
command line program to do that.

> 
> 
> 
> Any feedback from folks working on installers or from operators would
> be more than welcome!
> 
> Thanks,