+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 [bdobr...@redhat.com] Sent: Monday, June 12, 2017 1:07 AM To: email@example.com 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 <d...@doughellmann.com > <mailto:d...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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