On Sat, Aug 1, 2015 at 2:51 AM, Monty Taylor <mord...@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: avis...@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>
__________________________________________________________________________ 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