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 <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 :-)
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
