[openstack-dev] [neutron][L3] IPAM alternate refactoring

Jay Pipes jaypipes at gmail.com
Sun Apr 19 00:23:14 UTC 2015

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.


More information about the OpenStack-dev mailing list