Open Stack

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:
http://lists.openstack.org/pipermail/openstack-dev/2017-March/114246.html

Both threads are related, I would love to hear some feedback on it or
directly in the etherpad:
https://etherpad.openstack.org/p/tripleo-etcd-transition

Thanks,

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



-- 
Emilien Macchi