Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-27 Thread Jay Pipes
with concurrency of NeutronDbObject and oslo.versionedobject interfaces? Best, -jay *From: *Damon Wang *Reply-To: *OpenStack List *Date: *Tuesday, May 24, 2016 at 5:58 AM *To: *OpenStack List *Subject: *Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues Hi, I want to add an o

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-24 Thread John Schwarz
> From: Damon Wang > Reply-To: OpenStack List > Date: Tuesday, May 24, 2016 at 5:58 AM > To: OpenStack List > Subject: Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency > issues > > > > Hi, > > > > I want to add an option which handle by an

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-23 Thread Gary Kotton
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tooz&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67L

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-23 Thread Damon Wang
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 : > > On 16 May 2016, at 20:01, Michał Dulko wrote: > > It's

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-16 Thread Ilya Chukhnakov
> On 16 May 2016, at 20:01, Michał Dulko 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 prob

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-16 Thread Michał Dulko
On 05/16/2016 05:49 PM, Ilya Chukhnakov wrote: > On 16 May 2016, at 18:18, Michał Dulko > wrote: >> In Cinder we're handling similar problems related to race conditions >> between status check and status change with conditional updates. >> Basically we're doing "UPDA

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-16 Thread Ilya Chukhnakov
On 16 May 2016, at 18:18, Michał Dulko wrote: > In Cinder we're handling similar problems related to race conditions > between status check and status change with conditional updates. > Basically we're doing "UPDATE table SET status='abc' WHERE id=1 AND > status='status_allowing_transition_to_foo'

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-16 Thread Michał Dulko
On 05/12/2016 08:26 PM, Ilya Chukhnakov wrote: > Hi everyone. > > I’ve recently found that straightforward use of NeutronDbObject is prone to > concurrency-related problems. > > I’ve submitted a patch set [3] with some tests to show that without special > treatment using NeutronDbObject could lead

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-13 Thread Ilya Chukhnakov
> > [1] https://review.openstack.org/#/c/303966/11 > [2] https://review.openstack.org/#/c/225995 > [3] https://bugs.launchpad.net/neutron/+bug/1516195 > > -Original Message- > From: Ilya Chukhnakov [mailto:ichukhna...@mirantis.com] > Sent: Thursday, May 12, 2016 8:26

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-13 Thread Ilya Chukhnakov
>In a multi-writer galera cluster both SELECT FOR UPDATE and CAS won't fail >until commit time Good point, I did not consider multi-writer. But anyway, my point was that opt.2 is no worse than opt.1. > On 13 May 2016, at 12:04, Kevin Benton wrote: > > >While opt.2 only prevents the conflicti

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-13 Thread Kevin Benton
>While opt.2 only prevents the conflicting changes, but does not guarantee that the object does not change while within the context, I'm not sure what you mean here. In a multi-writer galera cluster both SELECT FOR UPDATE and CAS won't fail until commit time if someone writes to another server. So

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-13 Thread Kevin Benton
nal Message- > From: Ilya Chukhnakov [mailto:ichukhna...@mirantis.com] > Sent: Thursday, May 12, 2016 8:26 PM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues > > Hi everyone. > > I’ve recently found that

Re: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-13 Thread Korzeniewski, Artur
://bugs.launchpad.net/neutron/+bug/1516195 -Original Message- From: Ilya Chukhnakov [mailto:ichukhna...@mirantis.com] Sent: Thursday, May 12, 2016 8:26 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues Hi everyone. I’ve recently found that

[openstack-dev] [neutron][ovo] NeutronDbObject concurrency issues

2016-05-12 Thread Ilya Chukhnakov
Hi everyone. I’ve recently found that straightforward use of NeutronDbObject is prone to concurrency-related problems. I’ve submitted a patch set [3] with some tests to show that without special treatment using NeutronDbObject could lead to unexpected results. Further patch sets will provide acq