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).
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
