Open Stack

On Tue, Jun 6, 2017 at 6:24 PM, Doug Hellmann <doug at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Emilien Macchi