[openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd
flavio at redhat.com
Thu Jun 8 16:27:51 UTC 2017
On 08/06/17 18:23 +0200, Flavio Percoco wrote:
>On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote:
>>On 06.06.2017 18:08, Emilien Macchi wrote:
>>>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
>>It doesn't look a strict requirement. Those configs may (and should) be
>>bind-mounted into containers, as hostpath volumes. Or, am I missing
>>something what *does* make embedded configs a strict requirement?..
>mmh, one thing I liked about this effort was possibility of stop bind-mounting
>config files into the containers. I'd rather find a way to not need any
>bindmount and have the services get their configs themselves.
Probably sent too early!
If we're not talking about OpenStack containers running in a COE, I guess this
is fine. For k8s based deployments, I think I'd prefer having installers
creating configmaps directly and use that. The reason is that depending on files
that are in the host is not ideal for these scenarios. I hate this idea because
it makes deployments inconsistent and I don't want that.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 862 bytes
Desc: not available
More information about the OpenStack-dev