Monty Taylor wrote:
On 08/01/2015 03:40 AM, Mike Perez wrote:
On Fri, Jul 31, 2015 at 8:56 AM, Joshua Harlow<harlo...@outlook.com> wrote:
...random thought here, skip as needed... in all honesty orchestration
solutions like mesos
(http://mesos.apache.org/assets/img/documentation/architecture3.jpg),
map-reduce solutions like hadoop, stream processing systems like apache
storm (...), are already using zookeeper and I'm not saying we should just
use it cause they are, but the likelihood that they just picked it for no
reason are imho slim.
I'd really like to see focus cross project. I don't want Ceilometer to
depend on Zoo Keeper, Cinder to depend on etcd, etc. This is not ideal
for an operator to have to deploy, learn and maintain each of these
solutions.
I think this is difficult when you consider everyone wants options of
their preferred DLM. If we went this route, we should pick one.
Regardless, I want to know if we really need a DLM. Does Ceilometer
really need a DLM? Does Cinder really need a DLM? Can we just use a
hash ring solution where operators don't even have to know or care
about deploying a DLM and running multiple instances of Cinder manager
just works?
I'd like to take that one step further and say that we should also look
holistically at the other things that such technology are often used for
in distributed systems and see if, in addition to "Does Cinder need a
DLM" - ask "does Cinder need service discover" and "does Cinder need
distributed KV store" and does anyone else?
Adding something like zookeeper or etcd or consul has the potential to
allow us to design an OpenStack that works better. Adding all of them in
an ad-hoc and uncoordinated manner is a bit sledgehammery.
The Java community uses zookeeper a lot
The container orchestration community seem to all love etcd
I hear tell that there a bunch of ops people who are in love with consul
I'd suggest we look at more than lock management.
Oh I very much agree, but gotta start somewhere :)
__________________________________________________________________________
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
