Open Stack

On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar <pbondar at infoblox.com> 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