[openstack-dev] [neutron][L3] IPAM alternate refactoring
carl at ecbaldwin.net
Mon Apr 13 16:39:24 UTC 2015
On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar <pbondar at infoblox.com> wrote:
> I made some investigation on the topic and see several issues on this
> 1. Plugin's create_port() is wrapped up in top level transaction for
> create floating ip case, 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
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:
> So IPAM call should be added into create_floatingip to be outside db
> - for usual port create transaction is initialized on plugin's
> create_port level, and John's change cover this case:
> 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?
More information about the OpenStack-dev