[openstack-dev] [neutron][L3] IPAM alternate refactoring
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_router (starts tx)
> 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 and see several issues on this
>>1. Plugin's create_port() is wrapped up in top level transaction for
>>create floating ip case, so it becomes more complicated to do IPAM
>>calls outside main db transaction.
>>- for create floating ip case transaction is initialized on
>>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 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.
>> 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  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.
>>>  https://review.openstack.org/#/c/172443/
>>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
More information about the OpenStack-dev