Open Stack

> On Jun 7, 2017, at 7:20 AM, Emilien Macchi <emilien at redhat.com> wrote:
> 
> On Tue, Jun 6, 2017 at 6:08 PM, Emilien Macchi <emilien at redhat.com <mailto:emilien at 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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170607/10cc819d/attachment.html>