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

Doug Hellmann doug at doughellmann.com
Wed Mar 15 19:40:53 UTC 2017

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.


* your definition of "fun" may be different than mine

More information about the OpenStack-dev mailing list