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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev