Open Stack

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

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170608/df87d663/attachment.sig>