On Mon, Apr 13, 2015 at 8: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.
Is it time to look at breaking the bond between a floating and a port? I think the only reason that a port is created to back a floating IP is for IPAM because IP addresses are only reserved by creating a port with it. I'm sure this won't be very easy but I think it is worth a look to see what will be involved. > - 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 Ditto. > - 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. Yes, error handling could be problematic. I think there will always be the possibility of having an inconsistent state between the two systems. We should consider such failure modes and have a way to clean up. Is this cleanup the sort of thing that taskflow provides? Carl __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
