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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
