[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)
emilien at redhat.com
Tue Mar 21 16:49:26 UTC 2017
On Wed, Mar 15, 2017 at 3:53 PM, Paul Belanger <pabelanger at redhat.com> wrote:
> On Wed, Mar 15, 2017 at 09:41:16AM +0100, Thomas Herve wrote:
>> On Wed, Mar 15, 2017 at 12:05 AM, Joshua Harlow <harlowja at fastmail.com> wrote:
>> > * How does reloading work (does it)?
>> No. There is nothing that we can do in oslo that will make services
>> magically reload configuration. It's also unclear to me if that's
>> something to do. In a containerized environment, wouldn't it be
>> simpler to deploy new services? Otherwise, supporting signal based
>> reload as we do today should be trivial.
>> > * What's the operational experience (editing a ini file is about the lowest
>> > bar we can possible get to, for better and/or worse).
>> > * 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)
>> That's confd: https://github.com/kelseyhightower/confd/ . Bonus
>> points; it supports a ton of other backends. One solution is to
>> provide templates and documentation to use confd with OpenStack.
> Lets not get into the business of writing cfgmgmt tools in openstack, but reuse
> what exists today.
> oslo.config should just write to etcd, and other tools would be used, confd, to
> trigger things.
I agree with you and that's what we're investigating in TripleO:
Both threads are related, I would love to hear some feedback on it or
directly in the etherpad:
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev