Open Stack

On 19 April 2015 at 02:23, 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 already expressed my opinion on the matter in [1].
But I think you should stay focused on a viable strategy for taking IPAM
out of db_base_plugin_v2 and not make this another gargantuan task.


>
>
>    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).
>

The current logic makes non trivial to split transactions for port and
floating IP creation. Since at the end of day I hope we'll converge to a
consensus where that port isn't needed, I hope it will be not too difficult
to do the IPAM transactions separately and then pass to the operation which
creates the floating IP the IP address which was allocated for it on the
external network.


>
> Trying to trace the DB transaction scope through all the mess of mixin
> classes in Neutron is, well, extremely mind-boggling.
>

It is actually not that mind blogging... in general every method
corresponds to a single ginormous transaction without savepoints. What is
mindbloggin is following the evolution of said transaction across mixings
and understanding the myriad of point where it can abort.


>
> Best,
> -jay



[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024323.html

>
>
> __________________________________________________________________________
> 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/20150420/14af50ca/attachment.html>