Open Stack

On Sat, Aug 1, 2015 at 2:51 AM, Monty Taylor <mordred at inaugust.com> wrote:

> I hear tell that there a bunch of ops people who are in love with consul
>

At my company we love Consul.  We found it to be very scalable and
performant, gives us an easy-to-use k/v store, membership service, DNS,
etc.  We use it to load balance requests to our services and route requests
to active instances, including to openstack and mariadb+galera.  That said,
I don't know if something like Consul, etcd, or zookeeper need to be part
of openstack itself, or just part of the deployment (unless we decide to
store metadata in a kv store in place of the SQL DB - which is entirely
possible with some adjustments to openstack).

I find it hard to believe that Cinder really needs distributed locks.
AFAIU, there is one lock in the non-driver Cinder code to solve a race
between deleting a volume and creating a snapshot/clone from it.  You can
solve that with other methods.  I already proposed to use garbage
collection for deleting volumes - you can delete offline and before
deleting easily check the DB if there is an ongoing operation with the
given volume as a source.  If yes, just wait.  The bulk of the locks seem
to be in the drivers.  I find it hard to believe that the management APIs
of so many storage products cannot be called concurrently.  I think we
could solve many issues in Cinder with some requirements on drivers, such
as that they need to be able to run active-active with no distributed
locks.  Another requirement of idempotency would significantly ease
recovery pains I believe.

I very much agree with Mike's statement that "Cinder isn't as complex as
people are making it."  Well maybe it is, but it doesn't need to be. :-)


-- 
*Avishay Traeger, PhD*
*Architect*

Mobile: +972 54 447 1475
E-mail: avishay at stratoscale.com



Web <http://www.stratoscale.com/> | Blog <http://www.stratoscale.com/blog/>
 | Twitter <https://twitter.com/Stratoscale> | Google+
<https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts>
 | Linkedin <https://www.linkedin.com/company/stratoscale>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150801/0a63edf1/attachment.html>