<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 April 2015 at 02:23, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 04/13/2015 12:39 PM, Carl Baldwin wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar <<a href="mailto:pbondar@infoblox.com" target="_blank">pbondar@infoblox.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
I made some investigation on the topic[1] and see several issues on this<br>
way.<br>
<br>
1. Plugin's create_port() is wrapped up in top level transaction for<br>
create floating ip case[2], so it becomes more complicated to do IPAM<br>
calls outside main db transaction.<br>
</blockquote>
<br>
Is it time to look at breaking the bond between a floating and a port?<br>
</blockquote>
<br></span>
IMO, yes.</blockquote><div><br></div><div>I already expressed my opinion on the matter in [1].</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  I think the only reason that a port is created to back a floating IP<br>
is for IPAM because IP addresses are only reserved by creating a port<br>
with it.<br>
<br>
I'm sure this won't be very easy but I think it is worth a look to see<br>
what will be involved.<br>
</blockquote>
<br></span>
Why can't port creation be done entirely separately from assigning some *thing* -- i.e. a floating IP -- to that port?<br>
<br>
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).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Trying to trace the DB transaction scope through all the mess of mixin classes in Neutron is, well, extremely mind-boggling.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Best,<br>
-jay</blockquote><div><br></div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-January/024323.html">http://lists.openstack.org/pipermail/openstack-dev/2014-January/024323.html</a> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>