Open Stack

Excerpts from Steven Dake (stdake)'s message of 2017-06-08 17:51:48 +0000:
> Doug,
> 
> In short, a configmap takes a bunch of config files, bundles them in a kubernetes object called a configmap, and then ships them to etcd.  When a pod is launched, the pod mounts the configmaps using tmpfs and the raw config files are available for use by the openstack services.

That sounds like what confd does. Something puts data into one of
several possible databases. confd takes it out and writes it to
file(s) when the container starts. The app in the container reads
the file(s).

It sounds like configmaps would work well, too, it just doesn't
sound like a fundamentally different solution.

Doug

> 
> Operating on configmaps is much simpler and safer than using a different backing database for the configuration data.
> 
> Hope the information helps.
> 
> Ping me in #openstack-kolla if you have more questions.
> 
> Regards
> -steve
> 
> -----Original Message-----
> From: Doug Hellmann <doug at doughellmann.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Date: Thursday, June 8, 2017 at 10:12 AM
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla]    [helm] Configuration management with etcd / confd
> 
>     Excerpts from Flavio Percoco's message of 2017-06-08 18:27:51 +0200:
>     > 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
>     > 
>     
>     I'm not sure I understand how a configmap is any different from what is
>     proposed with confd in terms of deployment-specific data being added to
>     a container before it launches. Can you elaborate on that?
>     
>     Doug
>     
>     __________________________________________________________________________
>     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
>     
> 
> __________________________________________________________________________
> 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