[openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

Flavio Percoco flavio at redhat.com
Mon Jun 12 13:14:22 UTC 2017

On 12/06/17 10:07 +0200, Bogdan Dobrelya wrote:
>On 09.06.2017 18:51, Flavio Percoco wrote:
>> On Fri, Jun 9, 2017 at 8:07 AM Doug Hellmann <doug at doughellmann.com
>> <mailto:doug at doughellmann.com>> wrote:
>>     Excerpts from Flavio Percoco's message of 2017-06-08 22:28:05 +0000:
>>     > Unless I'm missing something, to use confd with an OpenStack
>>     deployment on
>>     > k8s, we'll have to do something like this:
>>     >
>>     > * Deploy confd in every node where we may want to run a pod (basically
>>     > wvery node)
>>     Oh, no, no. That's not how it works at all.
>>     confd runs *inside* the containers. It's input files and command line
>>     arguments tell it how to watch for the settings to be used just for that
>>     one container instance. It does all of its work (reading templates,
>>     watching settings, HUPing services, etc.) from inside the container.
>>     The only inputs confd needs from outside of the container are the
>>     connection information to get to etcd. Everything else can be put
>>     in the system package for the application.
>> A-ha, ok! I figured this was another option. In this case I guess we
>> would have 2 options:
>> 1. Run confd + openstack service in side the container. My concern in
>> this case
>> would be that we'd have to run 2 services inside the container and structure
>> things in a way we can monitor both services and make sure they are both
>> running. Nothing impossible but one more thing to do.
>> 2. Run confd `-onetime` and then run the openstack service.
>A sidecar confd container running in a shared pod, which is having a
>shared PID namespace with the managed service, would look much more
>containerish. So confd could still HUP the service or signal it to be
>restarted w/o baking itself into the container image. We have to deal
>with the Pod abstraction as we want to be prepared for future
>integration with k8s.

Yeah, this might work too. I was just trying to think of options that were
generic enough. In an k8s scenario, this should do the job.


Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170612/295781d4/attachment.sig>

More information about the OpenStack-dev mailing list