Open Stack

+1 for putting confd in a side car with shared namespaces. much more k8s native.

Still generally -1 on the approach of using confd instead of configmaps. You loose all the atomicity that k8s provides with deployments. It breaks upgrade/downgrade behavior.

Would it be possible to have confd run in k8s, generate the configmaps, and push them to k8s? That might be even more k8s native.

Thanks,
Kevin
________________________________________
From: Bogdan Dobrelya [bdobreli at redhat.com]
Sent: Monday, June 12, 2017 1:07 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

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.

>
> Either would work but #2 means we won't have config files monitored and the
> container would have to be restarted to update the config files.
>
> Thanks, Doug.
> Flavio
>
>
> __________________________________________________________________________
> 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
>


--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__________________________________________________________________________
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