Open Stack

On Wed, Mar 15, 2017 at 04:23:09AM +0100, Monty Taylor wrote:
> On 03/15/2017 12:05 AM, Joshua Harlow wrote:
> > So just fyi, this has been talked about before (but prob in context of
> > zookeeper or various other pluggable config backends).
> > 
> > Some links:
> > 
> > - https://review.openstack.org/#/c/243114/
> > - https://review.openstack.org/#/c/243182/
> > - https://blueprints.launchpad.net/oslo.config/+spec/oslo-config-db
> > - https://review.openstack.org/#/c/130047/
> > 
> > I think the general questions that seem to reappear are around the
> > following:
> > 
> > * How does reloading work (does it)?
> > 
> > * What's the operational experience (editing a ini file is about the
> > lowest bar we can possible get to, for better and/or worse).
> 
> As a person who operates many softwares (but who does not necessarily
> operate OpenStack specifically) I will say that services that store
> their config in a service that do not have an injest/update facility
> from file are a GIANT PITA to deal with. Config management is great at
> laying down config files. It _can_ put things into services, but that's
> almost always more work.
> 
> Which is my way of saying - neat, but please please please whoever
> writes this make a simple facility that will let someone plop config
> into a file on disk and get that noticed and slurped into the config
> service. A one-liner command line tool that one runs on the config file
> to splat into the config service would be fine.
> 
So much this! As an operator, I am fine plopping a config files down on a remote
node and understand what that means to my workflow.

Opt out by default! :)

> > * Does this need to be a new oslo.config backend or is it better suited
> > by something like the following (external programs loop)::
> > 
> >    etcd_client = make_etcd_client(args)
> >    while True:
> >        has_changed = etcd_client.get_new_config("/blahblah") # or use a
> > watch
> >        if has_changed:
> >           fetch_and_write_ini_file(etcd_client)
> >           trigger_reload()
> >        time.sleep(args.wait)
> > 
> > * Is an external loop better (maybe, maybe not?)
> > 
> > Pretty sure there are some etherpad discussions around this also somewhere.
> > 
> > Clint Byrum wrote:
> >> Excerpts from Davanum Srinivas's message of 2017-03-14 13:04:37 -0400:
> >>> Team,
> >>>
> >>> So one more thing popped up again on IRC:
> >>> https://etherpad.openstack.org/p/oslo.config_etcd_backend
> >>>
> >>> What do you think? interested in this work?
> >>>
> >>> Thanks,
> >>> Dims
> >>>
> >>> PS: Between this thread and the other one about Tooz/DLM and
> >>> os-lively, we can probably make a good case to add etcd as a base
> >>> always-on service.
> >>>
> >>
> >> This is a cool idea, and I think we should do it.
> >>
> >> A few loose ends I'd like to see in a spec:
> >>
> >> * Security Security Security. (Hoping if I say it 3 times a real
> >>    security person will appear and ask the hard questions).
> >> * Explain clearly how operators would inspect, edit, and diff their
> >>    configs.
> >>
> >> __________________________________________________________________________
> >>
> >> 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