Open Stack

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 <harlowja at outlook.com
> <mailto:harlowja at 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<harlowja at outlook.com <mailto:harlowja at 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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev