Open Stack

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>  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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev