We'll have a chance to discuss DB mutual exclusion at the API nodes at the Cider mid-cyle, which starts tomorrow. The details, issues, and realistic schedule for that will be a key piece to this whole puzzle, since anything else is seen as a temporary solution.
-----Original Message----- From: Gorka Eguileor [mailto:gegui...@redhat.com] Sent: Monday, August 03, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] A possible solution for HA Active-Active On Mon, Aug 03, 2015 at 07:01:45PM +1000, Morgan Fainberg wrote: > Lets step back away from tooz. Tooz for the sake of this conversation is as > much the same as saying zookeeper or consul or etcd, etc. We should be > focused (as both Flavio and Thierry said) on if we need DLM and what it will > solve. What do you mean we should be focused on if we need a DLM and what it will solve? I don't know what you mean, as those answers are quite clear: - The DLM replaces our current local file locks and extends them among nodes, it does not provide any additional functionality. - Do we need a DLM? Need is a strong word, if you are asking if we can do it without a DLM, then the answer is yes, we can do it without it. And if you ask if it will take more time than using a DLM and has the potential to introduce more bugs, then the answer is yes as well. - Will we keep using a DLM forever? No, we will change the DLM locks with DB mutual exclusion at the API nodes later. Gorka. > > Once we have all of that defined, the use of an abstraction such as tooz (or > just the direct bindings for some specific choice) can be made. > > I want to voice that we should be very picky about the solution (if we decide > on a DLM) so that we are implementing to the strengths of the solution rather > than try and make everything work seamlessly. > > --Morgan > > Sent via mobile > > >> On Aug 3, 2015, at 18:49, Julien Danjou <jul...@danjou.info> wrote: > >> > >> On Mon, Aug 03 2015, Thierry Carrez wrote: > >> > >> The last thing we want is to rush a solution that would only solve > >> a particular project use case. Personally I'd like us to pick the > >> simplest solution that can solve most of the use cases. Each of the > >> solutions bring something to the table -- Zookeeper is mature, > >> Consul is featureful, etcd is lean and simple... Let's not dive > >> into the best solution but clearly define the problem space first. > > > > Or just start using Tooz – like some of OpenStack are already doing > > for months – and let the operators pick the backend that they are > > the most comfortable with? :) > > > > -- > > Julien Danjou > > -- Free Software hacker > > -- http://julien.danjou.info > > ____________________________________________________________________ > > ______ 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 __________________________________________________________________________ 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
