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" <[email protected]> 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, [email protected] 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: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
