Flavio,
Atleast for the kubernetes variant of kolla, bindmounting will always be used
as this is fundamentally how configmaps operate. In order to maintain maximum
flexilbility and compatibility with kubernetes, I am not keen to try a
non-configmap way of doing things.
Regards
-steve
-----Original Message-----
From: Flavio Percoco <fla...@redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Thursday, June 8, 2017 at 9:23 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla]
[helm] Configuration management with etcd / confd
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.
Flavio
--
@flaper87
Flavio Percoco
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
