<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 8, 2017, 19:14 Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Flavio Percoco's message of 2017-06-08 18:27:51 +0200:<br>
> On 08/06/17 18:23 +0200, Flavio Percoco wrote:<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>
> Probably sent too early!<br>
><br>
> If we're not talking about OpenStack containers running in a COE, I guess this<br>
> is fine. For k8s based deployments, I think I'd prefer having installers<br>
> creating configmaps directly and use that. The reason is that depending on files<br>
> that are in the host is not ideal for these scenarios. I hate this idea because<br>
> it makes deployments inconsistent and I don't want that.<br>
><br>
> Flavio<br>
><br>
<br>
I'm not sure I understand how a configmap is any different from what is<br>
proposed with confd in terms of deployment-specific data being added to<br>
a container before it launches. Can you elaborate on that?<br>
<br></blockquote></div><div><br></div><div>Unless I'm<span style="font-size:13px"> missing something, to use confd with an OpenStack deployment on k8s, we'll have to do something like this:</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">* Deploy confd in every node where we may want to run a pod (basically wvery node)</span></div><div><span style="font-size:13px">* Configure it to download all configs from etcd locally (we won't be able to download just some of them because we don't know what services may run in specific nodes. Except, perhaps, in the case of compute nodes and some other similar nodes)</span></div><div><span style="font-size:13px">* Enable hostpath volumes (iirc it's disabled by default) so that we can mount these files in the pod</span></div><div><span style="font-size:13px">* Run the pods and mount the files assuming the files are there.</span></div><div><span style="font-size:13px"><br></span></div><div>All of the above is needed because  confd syncs files locally from etcd. Having a centralized place to manage these configs allows for controlling the deployment better. For example, if a configmap doesn't exist, then stop everything.</div><div><br></div><div>Not trying to be negative but rather explain why I think confd may not work well for the k8s based deployments. I think it's a good fit for the rest of the deployments.</div><div><br></div><div>Am I missing something? Am I overcomplicating things?</div><div><br></div><div>Flavio</div>