Open Stack

I think removing all occurrences of create_port inside of another
transaction is something we should be doing for a couple of reasons.

First, it's a recipe for the cherished "lock wait timeout" deadlocks
because create_port makes yielding calls. These are awful to troubleshoot
and are pretty annoying for users (request takes ~60 seconds and then blows
up).

Second, create_port in ML2 expects the transaction to be committed to the
DB by the time it's done with pre-commit phase, which we break by opening a
parent transaction before calling it so the failure handling semantics may
be messed up.



On Mon, Apr 13, 2015 at 9:48 AM, Carl Baldwin <carl at ecbaldwin.net> wrote:

> Have we found the last of them?  I wonder.  I suppose any higher level
> service like a router that needs to create ports under the hood (under
> the API) will have this problem.  The DVR fip namespace creation comes
> to mind.  It will create a port to use as the external gateway port
> for that namespace.  This could spring up in the context of another
> create_port, I think (VM gets new port bound to a compute host where a
> fip namespace needs to spring in to existence).
>
> Carl
>
> On Mon, Apr 13, 2015 at 10:24 AM, John Belamaric
> <jbelamaric at infoblox.com> wrote:
> > Thanks Pavel. I see an additional case in L3_NAT_dbonly_mixin, where it
> > starts the transaction in create_router, then eventually gets to
> > create_port:
> >
> > create_router (starts tx)
> >   ->self._update_router_gw_info
> >   ->_create_gw_port
> >   ->_create_router_gw_port
> >   ->create_port(plugin)
> >
> > So that also would need to be unwound.
> >
> > On 4/13/15, 10:44 AM, "Pavel Bondar" <pbondar at infoblox.com> wrote:
> >
> >>Hi,
> >>
> >>I made some investigation on the topic[1] and see several issues on this
> >>way.
> >>
> >>1. Plugin's create_port() is wrapped up in top level transaction for
> >>create floating ip case[2], so it becomes more complicated to do IPAM
> >>calls outside main db transaction.
> >>
> >>- for create floating ip case transaction is initialized on
> >>create_floatingip level:
> >>create_floatingip(l3_db)->create_port(plugin)->create_port(db_base)
> >>So IPAM call should be added into create_floatingip to be outside db
> >>transaction
> >>
> >>- for usual port create transaction is initialized on plugin's
> >>create_port level, and John's change[1] cover this case:
> >>create_port(plugin)->create_port(db_base)
> >>
> >>Create floating ip work-flow involves calling plugin's create_port,
> >>so IPAM code inside of it should be executed only when it is not wrapped
> >>into top level transaction.
> >>
> >>2. It is opened question about error handling.
> >>Should we use taskflow to manage IPAM calls to external systems?
> >>Or simple exception based model is enough to handle rollback actions on
> >>third party systems in case of failing main db transaction.
> >>
> >>[1] https://review.openstack.org/#/c/172443/
> >>[2] neutron/db/l3_db.py: line 905
> >>
> >>Thanks,
> >>Pavel
> >>
> >>On 10.04.2015 21:04, openstack-dev-request at lists.openstack.org wrote:
> >>> L3 Team,
> >>>
> >>> I have put up a WIP [1] that provides an approach that shows the ML2
> >>>create_port method refactored to use the IPAM driver prior to initiating
> >>>the database transaction. Details are in the commit message - this is
> >>>really just intended to provide a strawman for discussion of the
> >>>options. The actual refactor here is only about 40 lines of code.
> >>>
> >>> [1] https://review.openstack.org/#/c/172443/
> >>>
> >>>
> >>> Thanks,
> >>> John
> >>
> >>
>
> >>__________________________________________________________________________
> >>OpenStack Development Mailing List (not for usage questions)
> >>Unsubscribe:
> OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/2a2612da/attachment.html>