On 03/08/15 08:32 -0700, Joshua Harlow wrote:
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.So IMHO part of the problem with just thinking about a DLM is that most of the above (zk, consul, etcd) are much more than a simple DLM(s); that likely leads to over-thinking solutions...I'm all for a cross-project spec and chat and all that, as long as it goes somewhere, maybe the TC can try to work together with the community and make that happen (if they can free themselves from picking tags).
I believe that is exactly what we're trying to do in this thread. The TC won't just go and chat for an hour about whether other projects need a DLM or not. This is a community decision, which is why I asked for a cross-project spec were this discussion can be held. Once the problem has been laid down and we all have a clear understanding of what we need, then we can move forward. Just to be clear, the discussion I'm looking forward to see is on whether a DLM is something we need, what problmes we're trying to solve and how it'd benefit projects at large rather than a single project. I think Gorka did an amazing job defining what the problem for *Cinder* is and how a DLM would help there. Now we need to expand that to other projects that we know already would benefit from having one around. This, by any means, should block other works in Cinder w.r.t HA A/A. Cheers, Flavio
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 mobileOn 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
-- @flaper87 Flavio Percoco
pgp7Qx8EClBJI.pgp
Description: PGP signature
__________________________________________________________________________ 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
