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