[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

Doug Hellmann doug at doughellmann.com
Thu Apr 6 23:08:36 UTC 2017


Excerpts from Emilien Macchi's message of 2017-04-06 18:17:59 -0400:
> On Wed, Mar 22, 2017 at 11:23 AM, Flavio Percoco <flavio at redhat.com> wrote:
> > On 15/03/17 15:40 -0400, Doug Hellmann wrote:
> >>
> >> Excerpts from Monty Taylor's message of 2017-03-15 04:36:24 +0100:
> >>>
> >>> On 03/14/2017 06:04 PM, Davanum Srinivas wrote:
> >>> > 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.
> >>>
> >>> As I mentioned in the other thread, there was specific and strong
> >>> anti-etcd sentiment in Tokyo which is why we decided to use an
> >>> abstraction. I continue to be in favor of us having one known service in
> >>> this space, but I do think that it's important to revisit that decision
> >>> fully and in context of the concerns that were raised when we tried to
> >>> pick one last time.
> >>>
> >>> It's worth noting that there is nothing particularly etcd-ish about
> >>> storing config that couldn't also be done with zk and thus just be an
> >>> additional api call or two added to Tooz with etcd and zk drivers for it.
> >>>
> >>
> >> The fun* thing about working with these libraries is managing the
> >> interdependencies. If we're going to have an abstraction library that
> >> provides configuration options for seeing the backend, like we do in
> >> oslo.db and olso.messaging, then the configuration library can't use it
> >> or we have a circular dependency.
> >>
> >> Luckily, tooz does not currently use oslo.config. So, oslo.config could
> >> use tooz and we could create an oslo.dlm library with a shallow
> >> interface mapping config options to tooz calls to open connections or
> >> whatever we need from tooz in an application. Then apps could use
> >> oslo.dlm instead of calling into tooz directly and the configuration of
> >> the backend would be hidden from the application developer.
> >
> >
> > Replying here becasue I like the proposal, I like what Monty said and I also
> > like what Doug said. Most of the issues and concerns have been covered in
> > this
> > thread and I don't have much else to add other than +1.
> 
> The one-million-dollar question now is: what are the next steps?
> It sounds like an oslo spec would be nice to summarize the ideas here
> and talk about design.
> 
> I volunteer to help but I would need someone more familiar than I am with Oslo.
> Please let me know if you're interested to work on it with me
> otherwise I'll chase chase some of you :-)

I can help from the Oslo side.

Doug

> 
> Thanks for the nice discussions here, I think we've made good progress.
> 
> >> Doug
> >>
> >> * your definition of "fun" may be different than mine
> >
> >
> > Which is probably different than mine :)
> >
> > --
> > @flaper87
> > Flavio Percoco
> >
> > __________________________________________________________________________
> > 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