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

Fox, Kevin M Kevin.Fox at pnnl.gov
Mon Jun 12 17:38:08 UTC 2017


"Otherwise, -onetime will need to launch new containers each config change." You say that like its a bad thing....

That sounds like a good feature to me. atomic containers. You always know the state of the system. As an Operator, I want to know which containers have the new config, which have the old, and which are stuck transitioning so I can fix brokenness. If its all hidden inside the containers, its much harder to Operate.

Thanks,
Kevin
________________________________________
From: Paul Belanger [pabelanger at redhat.com]
Sent: Friday, June 09, 2017 10:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [deployment] [oslo] [ansible] [tripleo] [kolla] [helm] Configuration management with etcd / confd

On Fri, Jun 09, 2017 at 04:52:25PM +0000, Flavio Percoco wrote:
> On Fri, Jun 9, 2017 at 11:30 AM Britt Houser (bhouser) <bhouser at cisco.com>
> wrote:
>
> > How does confd run inside the container?  Does this mean we’d need some
> > kind of systemd in every container which would spawn both confd and the
> > real service?  That seems like a very large architectural change.  But
> > maybe I’m misunderstanding it.
> >
> >
> Copying part of my reply to Doug's email:
>
> 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.
>
>
> I either case, we could run confd as part of the entrypoint and have it run
> in
> background for the case #1 or just run it sequentially for case #2.
>
Both approached are valid, it all depends on your use case.  I suspect in the
case of openstack, you'll be running 2 daemons in your containers. Otherwise,
-onetime will need to launch new containers each config change.

>
> > Thx,
> > britt
> >
> > On 6/9/17, 9:04 AM, "Doug Hellmann" <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.
> >
> >     Doug
> >
> >
> > __________________________________________________________________________
> >     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
> >
> >
> > __________________________________________________________________________
> > 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
> >

> __________________________________________________________________________
> 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


__________________________________________________________________________
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



More information about the OpenStack-dev mailing list