Open Stack

On 06.06.2017 18:08, Emilien Macchi wrote:
> 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!
> 

Great progress, well 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.

This sounds like a plan to start following just immediately :-)

> 
> 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.

And that's really great as we need no to reimplement confd for oslo.config.

> 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).
> 
> 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.

It doesn't look a strict requirement. Those configs may (and should) be
bind-mounted into containers, as hostpath volumes. Or, am I missing
something what *does* make embedded configs a strict requirement?..

> 
> 
> == 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.
> 
> 
> 
> Any feedback from folks working on installers or from operators would
> be more than welcome!
> 
> Thanks,
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando