> On Jun 7, 2017, at 7:20 AM, Emilien Macchi <emil...@redhat.com> wrote: > > On Tue, Jun 6, 2017 at 6:08 PM, Emilien Macchi <emil...@redhat.com > <mailto:emil...@redhat.com>> 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! >> >> >> == 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. > > I'm also wondering if we could use oslo-config-generate directly to > generate confd templates, with a new format. So we would have ini, > yaml, json and confd. > "confd" format would be useful when building rpms that we ship in containers. > "yaml" format would be useful for installers to expose the options > directly to the User Interface, so we know which params OpenStack > provide and we could re-use the data to push it into etcd. > > Would it make sense?
I did think about making oslo-config-generator also take the YAML file as input instead of scanning plugins, and then including all the output formats in the single command. I haven’t looked to see how much extra complexity that would add. > >> 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 > > > > -- > Emilien Macchi > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev