On Thu, Nov 21, 2013 at 12:34:33PM -0800,
Gary Duan 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. OVS/linux bridge
See inline,
On Thu, Nov 21, 2013 at 2:19 AM, Isaku Yamahata wrote:
> On Wed, Nov 20, 2013 at 10:16:46PM -0800,
> Gary Duan 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
On Wed, Nov 20, 2013 at 10:16:46PM -0800,
Gary Duan 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 on L3 code, we
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.
https://blueprints.launchpad.net/neutron/+spec/l3-router
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" wrote:
>On Tue, Nov 19, 2013 at 08:59:38AM -0800,
>Edgar Magana wrote:
>
>> Do you have in mind any impl
On Tue, Nov 19, 2013 at 11:22:46PM +0100,
Salvatore Orlando 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 on the backend
>
stack-dev] [Neutron] Race condition between DB layer and
plugin back-end implementation
On Tue, Nov 19, 2013 at 08:59:38AM -0800, Edgar Magana
wrote:
> Do you have in mind any implementation, any BP?
> We could actually work on this together, all plugins will get the
> benefi
On Tue, Nov 19, 2013 at 08:59:38AM -0800,
Edgar Magana 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 somewhat old.
So needs t
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 %(resource_type)
M
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc: Joshua Harlow , Isaku Yamahata <
> isaku.yamah...@gmail.com>, Robert Kukura
> Subject: Re: [openstack-dev] [Neutron] Race condition between DB lay
t;>
Cc: Joshua Harlow mailto:harlo...@yahoo-inc.com>>,
Isaku Yamahata mailto:isaku.yamah...@gmail.com>>,
Robert Kukura mailto:rkuk...@redhat.com>>
Subject: Re: [openstack-dev] [Neutron] Race condition between DB layer and
plugin back-end implementation
For what is worth we
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:
- reliabili
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" wrote:
>If you start adding these states you might really want to consider the
>
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:
- https://etherp
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" wrote:
>On Mon, Nov 18, 2013 at 03:55:49PM -0500,
>Robert Kukura wrote:
>
>> On 11
On Mon, Nov 18, 2013 at 03:55:49PM -0500,
Robert Kukura 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 MechanismDrive
There are few examples of ML2 mechanism drivers. You can look at Arista ML2
driver. We deal with the DB synchronization as well back-end
provisioning. We deal with back-end failures and roll-backs as well
synchronization between Neutron and back-end.
best of luck
-Sukhdev
On Mon, Nov 18, 2013 a
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 pr
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 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
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
tran
@lists.openstack.org>
> Date: Monday, November 18, 2013 12:25 PM
> To: OpenStack List
> 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 remembe
k.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 API calls are sent to Neutron, all of them are se
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
24 matches
Mail list logo