On Tue, Jun 6, 2017 at 6:24 PM, Doug Hellmann <d...@doughellmann.com> wrote: > 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.
Indeed, thanks for the addition. >> 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. Right, but my point is keystone.conf would be generated at container startup for example. It's ok I think but I've heard some feedback where some folks wanted to not having config files at all. Anyway, I think this is still a great progress forward. >> >> >> == 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. A simple tool to push OpenStack parameters into etcd. The tool would be simple though, it could take a YAML file with parameters + values and push it into etcd maybe. I thought we could agree on some kind of format, so all installers would use the same tooling. It doesn't have to be in oslo.conf, but I thought useful to discuss it early, so we don't duplicate this effort. >> >> >> >> Any feedback from folks working on installers or from operators would >> be more than welcome! >> >> Thanks, > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Emilien Macchi _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
