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