Open Stack

On Thu, Jun 8, 2017, 19:51 Steven Dake (stdake) <stdake at cisco.com> wrote:

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

I was referring​ to bindmounts of files that were created in the host and
reside in the host. While configmaps are bindmounts, they don't really live
in the host until the pod/container is created.

Flavio


> Regards
> -steve
>
> -----Original Message-----
> From: Flavio Percoco <flavio at redhat.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Thursday, June 8, 2017 at 9:23 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170608/e18483bf/attachment.html>