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 <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.
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 -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
