[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.
Best,
-jay
More information about the OpenStack-dev
mailing list