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). 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. == 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, -- Emilien Macchi _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
