Open Stack

There are two ports when referring to the ones related to a floating IP.

There is the one the floating IP gets 'associated' with that is usually
attached to a VM. That one is created in a separate transaction and the
association gets its own transaction as well. That's all good.

The other port is the problem child. Currently, in order to get an IP
address for the floating IP itself, a dummy neutron port has to be created
just for the sake of getting the IP allocation. Since the floating IP is
handled in the L3 plugin and the port for it is handled in the core plugin,
we run into these transaction issues.

The floating IP has a non-nullable FK relationship to the port table for
its dummy port so we have to create the port first. If we don't put the
floating IP and the port under the same transaction, a failure during the
creation of the floating IP could result in an orphaned dummy port. These
orphans are particularly problematic because they waste external network IP
addresses and they are invisible to the tenant trying to allocate the
floating IP so he/she can't clean them up.

What Carl would like to do is eliminate the dummy port entirely, which
makes sense. Unfortunately, in order to do that we have to tweak a lot of
stuff to break the binding between an IP allocation and a port.

It's probably something we will have to do early in Liberty because I
imagine it will break in weird places, especially for L3 vendor plugins
that make assumptions about the presence of a port for other things (e.g.
the choice of MAC address to use for the floating IP traffic).

I hopes that helps clarify the issue.
On Apr 18, 2015 5:27 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

> On 04/13/2015 12:39 PM, Carl Baldwin wrote:
>
>> 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?
>>
>
> IMO, yes.
>
>    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.
>>
>
> Why can't port creation be done entirely separately from assigning some
> *thing* -- i.e. a floating IP -- to that port?
>
> The creation of a port can be done in a separate DB transaction.
> Assignment of said port ID to a floating IP resource can be done in a
> separate DB transaction (or external IPAM system call).
>
> Trying to trace the DB transaction scope through all the mess of mixin
> classes in Neutron is, well, extremely mind-boggling.
>
> Best,
> -jay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150418/89a5c56d/attachment.html>