[openstack-dev] [neutron][L3] IPAM alternate refactoring

Carl Baldwin carl at ecbaldwin.net
Mon Apr 13 16:48:43 UTC 2015

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).


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:
>>I made some investigation on the topic[1] and see several issues on this
>>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:
>>So IPAM call should be added into create_floatingip to be outside db
>>- for usual port create transaction is initialized on plugin's
>>create_port level, and John's change[1] cover this case:
>>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
>>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
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list