Open Stack

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