On Thu, Nov 21, 2013 at 12:34:33PM -0800,
Gary Duan gd...@varmour.com wrote:
Advanced service plugins don't have two-step transition today. IMO, If
vendor plugins/drivers don't maintain their own databases for these
services, it might not be urgent to add these steps in the plugin.
I agree.
On Wed, Nov 20, 2013 at 10:16:46PM -0800,
Gary Duan gd...@varmour.com wrote:
Hi, Isaku and Edgar,
Hi.
As part of the effort to implement L3 router service type framework, I have
reworked L3 plugin to introduce a 2-step process, precommit and postcommit,
similar to ML2. If you plan to work
See inline,
On Thu, Nov 21, 2013 at 2:19 AM, Isaku Yamahata isaku.yamah...@gmail.comwrote:
On Wed, Nov 20, 2013 at 10:16:46PM -0800,
Gary Duan gd...@varmour.com wrote:
Hi, Isaku and Edgar,
Hi.
As part of the effort to implement L3 router service type framework, I
have
reworked L3
On Tue, Nov 19, 2013 at 08:59:38AM -0800,
Edgar Magana emag...@plumgrid.com wrote:
Do you have in mind any implementation, any BP?
We could actually work on this together, all plugins will get the benefits
of a better implementation.
Yes, let's work together. Here is my blueprint (it's
-dev] [Neutron] Race condition between DB layer and
plugin back-end implementation
On Tue, Nov 19, 2013 at 08:59:38AM -0800, Edgar Magana emag...@plumgrid.com
wrote:
Do you have in mind any implementation, any BP?
We could actually work on this together, all plugins will get the
benefits
On Tue, Nov 19, 2013 at 11:22:46PM +0100,
Salvatore Orlando sorla...@nicira.com wrote:
For what is worth we have considered this aspect from the perspective of
the Neutron plugin my team maintains (NVP) during the past release cycle.
The synchronous model that most plugins with a controller
Let me take a look and circle back to you in a bit. This is a very
sensitive part of the code, so we need to
Handle properly any change.
Thanks,
Edgar
On 11/20/13 5:46 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Tue, Nov 19, 2013 at 08:59:38AM -0800,
Edgar Magana emag...@plumgrid.com
Hi, Isaku and Edgar,
As part of the effort to implement L3 router service type framework, I have
reworked L3 plugin to introduce a 2-step process, precommit and postcommit,
similar to ML2. If you plan to work on L3 code, we can collaborate.
On Mon, Nov 18, 2013 at 03:55:49PM -0500,
Robert Kukura rkuk...@redhat.com wrote:
On 11/18/2013 03:25 PM, Edgar Magana wrote:
Developers,
This topic has been discussed before but I do not remember if we have a
good solution or not.
The ML2 plugin addresses this by calling each
Isaku,
Do you have in mind any implementation, any BP?
We could actually work on this together, all plugins will get the benefits
of a better implementation.
Thanks,
Edgar
On 11/19/13 3:57 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote:
On Mon, Nov 18, 2013 at 03:55:49PM -0500,
Robert
If you start adding these states you might really want to consider the
following work that is going on in other projects.
It surely appears that everyone is starting to hit the same problem (and
joining efforts would produce a more beneficial result).
Relevant icehouse etherpads:
-
And also of course, nearly forgot a similar situation/review in heat.
https://review.openstack.org/#/c/49440/
Except theres was/is dealing with stack locking (a heat concept).
On 11/19/13 10:33 AM, Joshua Harlow harlo...@yahoo-inc.com wrote:
If you start adding these states you might really
For what is worth we have considered this aspect from the perspective of
the Neutron plugin my team maintains (NVP) during the past release cycle.
The synchronous model that most plugins with a controller on the backend
currently implement is simple and convenient, but has some flaws:
-
Cc: Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com,
Isaku Yamahata isaku.yamah...@gmail.commailto:isaku.yamah...@gmail.com,
Robert Kukura rkuk...@redhat.commailto:rkuk...@redhat.com
Subject: Re: [openstack-dev] [Neutron] Race condition between DB layer and
plugin back-end
isaku.yamah...@gmail.com, Robert Kukura rkuk...@redhat.com
Subject: Re: [openstack-dev] [Neutron] Race condition between DB layer
and plugin back-end implementation
For what is worth we have considered this aspect from the perspective
of the Neutron plugin my team maintains (NVP) during the past
Hi Edgar,
We had a similar issue and worked around by something like the following
(which I believe similar to what Aaron said):
@@ -45,6 +45,8 @@ SNAT_RULE_PROPERTY = {OS_TENANT_ROUTER_RULE_KEY: SNAT_RULE}
class MidonetResourceNotFound(q_exc.NotFound):
message = _('MidoNet
Developers,
This topic has been discussed before but I do not remember if we have a good
solution or not.
Basically, if concurrent API calls are sent to Neutron, all of them are sent
to the plug-in level where two actions have to be made:
1. DB transaction No just for data persistence but also
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Race condition between DB layer and
plugin back-end implementation
Developers,
This topic has been discussed before but I do not remember if we have a
good solution or not.
Basically, if concurrent
On 11/18/2013 03:25 PM, Edgar Magana wrote:
Developers,
This topic has been discussed before but I do not remember if we have a
good solution or not.
The ML2 plugin addresses this by calling each MechanismDriver twice. The
create_network_precommit() method is called as part of the DB
On 11/18/2013 02:25 PM, Edgar Magana wrote:
The problem that we are experiencing is when concurrent calls to the
same API are sent, the number of operation at the plug-in back-end are
long enough to make the next concurrent API call to get stuck at the DB
transaction level, which creates a hung
Hi All,
Thank you everybody for your input. It is clear that any solution requires
changes at the plugin level (we were trying to avoid that). So, I am
wondering if a re-factor of this code is needed of not (maybe not).
The ML2 solution is probably the best alternative right now, so we may go
for
On 11/18/2013 05:21 PM, Edgar Magana wrote:
Hi All,
Thank you everybody for your input. It is clear that any solution requires
changes at the plugin level (we were trying to avoid that). So, I am
wondering if a re-factor of this code is needed of not (maybe not).
The ML2 solution is
22 matches
Mail list logo
