<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 8, 2017, 19:51 Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Flavio,<br>
<br>
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.<br></blockquote></div><div><br></div><div>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.</div><div><br></div><div>Flavio</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards<br>
-steve<br>
<br>
-----Original Message-----<br>
From: Flavio Percoco <<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>><br>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Date: Thursday, June 8, 2017 at 9:23 AM<br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd<br>
<br>
    On 07/06/17 12:04 +0200, Bogdan Dobrelya wrote:<br>
    >On 06.06.2017 18:08, Emilien Macchi wrote:<br>
    >> Another benefit is that confd will generate a configuration file when<br>
    >> the application will start. So if etcd is down *after* the app<br>
    >> startup, it shouldn't break the service restart if we don't ask confd<br>
    >> to re-generate the config. It's good for operators who were concerned<br>
    >> about the fact the infrastructure would rely on etcd. In that case, we<br>
    >> would only need etcd at the initial deployment (and during lifecycle<br>
    >> actions like upgrades, etc).<br>
    >><br>
    >> The downside is that in the case of containers, they would still have<br>
    >> a configuration file within the container, and the whole goal of this<br>
    >> feature was to externalize configuration data and stop having<br>
    >> configuration files.<br>
    ><br>
    >It doesn't look a strict requirement. Those configs may (and should) be<br>
    >bind-mounted into containers, as hostpath volumes. Or, am I missing<br>
    >something what *does* make embedded configs a strict requirement?..<br>
<br>
    mmh, one thing I liked about this effort was possibility of stop bind-mounting<br>
    config files into the containers. I'd rather find a way to not need any<br>
    bindmount and have the services get their configs themselves.<br>
<br>
    Flavio<br>
<br>
<br>
    --<br>
    @flaper87<br>
    Flavio Percoco<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>