<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 February 2015 at 19:57, John Belamaric <span dir="ltr"><<a href="mailto:jbelamaric@infoblox.com" target="_blank">jbelamaric@infoblox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, February 12, 2015 at 8:36 AM<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [Neutron] Update on "DB" IPAM driver<br>
</div><span class="">
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">Hi,
<div><br>
</div>
<div>I have updated the patch; albeit not complete yet it's kind of closer to be an allocator decent enough to replace the built-in logic.</div>
<div><br>
</div>
<div>I will be unable to attend today's L3/IPAM meeting due to a conflict, so here are some highlights from me on which your feedback is more than welcome:</div>
<div><br>
</div>
<div>- I agree with Carl that the IPAM driver should not have explicit code paths for autoaddress subnets, such as DHCPv6 stateless ones. In that case, the consumer of the driver will generate the address and then to the IPAM driver that would just be allocation
 of a specific address. However, I have the impression the driver still needs to be aware of whether the subnet has an automatic address mode or not - since in this case 'any' address allocation won't be possible. There already comments about this in the review
 [1]</div>
</div>
</div>
</div>
</blockquote>
</span></span>
<div><br>
</div>
<div>I think the auto-generated case should be a base class as you described in [1], but each subclass would implement the specific auto-generation. See the discussion at line 468 in [2] and see what you think. Of course for addresses that come from RA there
 would be no IPAM.</div></div></blockquote><div><br></div><div>I think this makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><br>
</div>
<div>
<div>[1] <a href="https://review.openstack.org/#/c/150485/" target="_blank">https://review.openstack.org/#/c/150485/</a></div>
</div>
<div>[2] <a href="https://review.openstack.org/#/c/153236/2/neutron/db/db_base_plugin_v2.py,unified" target="_blank">https://review.openstack.org/#/c/153236/2/neutron/db/db_base_plugin_v2.py,unified</a></div><span class="">
<div><br>
</div>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>- We had a discussion last week on whether the IPAM driver and neutron should 'share' database tables. I went back and forth a lot of time, but now to me it seems the best thing to do is to have the IPAM driver maintain an 'ip_requests' tables, where it
 stores allocation info. This table partially duplicates data in IPAllocation, but on the plus side it makes the IPAM driver self sufficient. The next step would be to decide whether we want to go a step further and also assume the driver should not access
 at all Neutron's DB, but I would defer that discussion to the next iteration (for both the driver and the IPAM interface)</div>
<div><br>
</div>
<div>- I promised a non blocking algorithm for IP allocation. The one I was developing was based on specifying the primary key on the ip_requests table in a way that it would prevent two concurrent requests from getting the same address, and would just retry
 getting an address until the primary key constraint was satisfied. However, recent information emerged on MySQL galera's (*) data set [2] certification  clarified that this kind of algorithm would still result in a deadlock error from failed data set certification.
 It is worth noting that in this case a solution based on traditional compare-and-swap is not possible because concurrent requests would be inserting data at the same time. I am now working on an alternative solution, and I would like to first implement a PoC
 for it (so that I can prove it works).</div>
<div><br>
</div>
<div>- The db base refactoring being performed by Pavel is under way [3]. It is worth noting that this is a non-negligible change to some of Neutron's basic and more critical workflows. We should expect pushback from the community regarding the introduction
 of this change in the 3rd milestone. At this stage I would suggest either:</div>
<div>A) consider a strategy for running pluggable IPAM as optional</div>
<div>B) consider delaying to Liberty.</div>
<div>(and that's where I get virtually jeered and pelted with rotten tomatoes)</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</span><div>I wish I had some old tomatoes! Seriously, I think "A" is a reasonable approach. To make this really explicit we may want to basically replace the DB plugin class with a shim that delegates to either the current implementation or the new implementation,
 depending on the flag.</div></div></blockquote><div><br></div><div>The fact that the current implementation is pretty much a bunch of private methods in the db base plugin class executed within a transaction for creating a port makes the situation a wee bit more complex. I'm not sure we can replace the db plugin class with a shim so easily, because we need to consider the impact on plugins which inherit from this base class. For instance some plugins override methods from the base class, and this would be a problem. For those plugins we must ensure old-style IPAM is performed. A transitory solution might be to have, for the relevant methods 2 versions - one would be the current one, and the other one would be the one leveraging pluggable IPAM. During plugin initialisation, the plugin itself will decide whether use or not the latter methods. This might be tuneable with a configuration parameter too. The downside of this approach is that it will not allow us to remove "old" baked in IPAM code, and will have an impact on code maintainability which ultimately will result in accumulating even more technical debt. However, I might be missing some better alternative, so if you have any proposal just let me know.</div><div><br></div><div>Salvatore </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span class="">
<div> </div>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>Thanks for reading this post,</div>
<div>Salvatore</div>
<div><br>
</div>
<div>[1] <a href="https://review.openstack.org/#/c/150485/" target="_blank">https://review.openstack.org/#/c/150485/</a></div>
<div>[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-February/056007.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-February/056007.html</a></div>
<div>[3] <a href="https://review.openstack.org/#/c/153236/" target="_blank">https://review.openstack.org/#/c/153236/</a></div>
</div>
</div>
</div>
</blockquote>
</span>
</span></div>

<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>
<br></blockquote></div><br></div></div>