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