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
