<p dir="ltr">There are two ports when referring to the ones related to a floating IP. </p>
<p dir="ltr">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. </p>
<p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<p dir="ltr">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). </p>
<p dir="ltr">I hopes that helps clarify the issue. </p>
<div class="gmail_quote">On Apr 18, 2015 5:27 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/13/2015 12:39 PM, Carl Baldwin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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:0 0 0 .8ex;border-left:1px #ccc 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>
IMO, yes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
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>
<br>
Trying to trace the DB transaction scope through all the mess of mixin classes in Neutron is, well, extremely mind-boggling.<br>
<br>
Best,<br>
-jay<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>
</blockquote></div>