The incorporation of tooz and Neutron is being discussed as part of https://bugs.launchpad.net/neutron/+bug/1552680 as an RFE for Newton. Hopefully I'll have some news to break in on this matter in the upcoming days (and if I do I'll update on the launchpad to eliminate duplicity).
On Tue, May 24, 2016 at 8:54 AM, Gary Kotton <gkot...@vmware.com> wrote: > Hi, > > We have used tooz to enable concurrency. Zookeeper and Redis worked well. I > think that it is certainly something that we need to consider. The challenge > becomes a deployment. > > Thanks > > Gary > > > > From: Damon Wang <damon.dev...@gmail.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Tuesday, May 24, 2016 at 5:58 AM > To: OpenStack List <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency > issues > > > > Hi, > > > > I want to add an option which handle by another project Tooz. > > > > https://github.com/openstack/tooz > > > > with redis or some other drivers, it seems pretty a good choice. > > > > Any comments? > > > > Wei Wang > > > > 2016-05-17 6:53 GMT+08:00 Ilya Chukhnakov <ichukhna...@mirantis.com>: > > > > On 16 May 2016, at 20:01, Michał Dulko <michal.du...@intel.com> wrote: > > > It's not directly related, but this reminds me of tests done by geguileo > [1] some time ago that were comparing different methods of preventing DB > race conditions in concurrent environment. Maybe you'll also find them > useful as you'll probably need to do something like conditional update > to increment a revision number. > > [1] https://github.com/Akrog/test-cinder-atomic-states > > > > Thanks for the link. The SQLA revisions are similar to the > 'solutions/update_with_where', > > but they use the dedicated column for that [2]. And as long as it is > properly configured, > > it happens 'automagically' (SQLA will take care of adding proper 'where' to > 'update'). > > > > [2] http://docs.sqlalchemy.org/en/latest/orm/versioning.html > > > __________________________________________________________________________ > 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 > > > > > __________________________________________________________________________ > 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 > -- John Schwarz, Red Hat. __________________________________________________________________________ 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