Re: [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

Doug Hellmann-2
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.

> 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.

>
>
> == 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.

>
>
>
> Any feedback from folks working on installers or from operators would
> be more than welcome!
>
> Thanks,

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

Emilien Macchi-4
On Tue, Jun 6, 2017 at 6:24 PM, Doug Hellmann <[hidden email]> 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
> [hidden email]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Emilien Macchi

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Loading...