Open Stack

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