Daniel Comnea wrote:
From Operators point of view i'd love to see less technology
proliferation in OpenStack, if you wear the developer hat please don't
be selfish, take into account the others :)
ZK is a robust technology but hey is a beast like Rabbit, there is a lot
to massage and over 2 data centers ZK is not very efficient.
Very much understand the operator view here, IMHO in its current state
according to http://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/
I'd say the operators of cinder in are a much worse boat right now, and
adding a robust technology in that could help the current state doesn't
exactly seem that bad.
IMHO if you are planning to (or are) running a cloud you are likely
going to have to be running zookeeper or similar service soon if you
aren't already anyway; because most cloudy projects already depend on
such services (for service discovery, configuration
discovery/management, DLM locking, fault detection, leader election...)
As for the 2 data centers, afaik the following is making this better:
https://zookeeper.apache.org/doc/trunk/zookeeperObservers.html
On Sat, Aug 1, 2015 at 4:27 AM, Joshua Harlow <harlo...@outlook.com
<mailto:harlo...@outlook.com>> wrote:
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 <mailto: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://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://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
