On Wed, Mar 22, 2017 at 11:23 AM, Flavio Percoco <fla...@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 :-) 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __________________________________________________________________________ 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