<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 February 2015 at 12:40, Rossella Sblendido <span dir="ltr"><<a href="mailto:rsblendido@suse.com" target="_blank">rsblendido@suse.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=""><br>
<br>
On 02/12/2015 02:36 PM, Salvatore Orlando wrote:<br>
> - I promised a non blocking algorithm for IP allocation. The one I was<br>
> developing was based on specifying the primary key on the ip_requests<br>
> table in a way that it would prevent two concurrent requests from<br>
> getting the same address, and would just retry getting an address until<br>
> the primary key constraint was satisfied. However, recent information<br>
> emerged on MySQL galera's (*) data set [2] certification  clarified that<br>
> this kind of algorithm would still result in a deadlock error from<br>
> failed data set certification. It is worth noting that in this case a<br>
> solution based on traditional compare-and-swap is not possible because<br>
> concurrent requests would be inserting data at the same time. I am now<br>
> working on an alternative solution, and I would like to first implement<br>
> a PoC for it (so that I can prove it works).<br>
<br>
</span>Would something like the following work: insert the data in the DB, if<br>
any error is got open a new transaction and try again ? enikanorov<br>
proposed a retry mechanism here [1] . Can't wait for your POC! I had<br>
been playing a while in the past to try to remove the locking from the<br>
IP allocation, it's hard!<br></blockquote><div><br></div><div>Retry is always an option, however the mechanism with the separate driver would be a bit different, since we need to identify conflicts before storing the IP allocation entry.</div><div>As a matter of fact, we're indeed splitting the IPAM transaction from the transaction which creates or updates the port.</div><div>The patch you linked is a mechanism for retrying a database transaction which can be adopted in any case, and is perhaps worth adopting also in the IPAM case - if nothing else to avoid code duplication.</div><div>However, what I am aiming for is a lock-free and wait-free algorithm that does not make assumptions on the isolation level. If that would not be practical, there are several alternatives to be considered:</div><div>- Leveraging unique constraint violations, and then trying different IPs until the constraint is not satisfied. This is apparently easy, but availability ranges can be quite tricky when you remove locking.</div><div>- Trying whether ti would be possible do so some sort of compare and swap on IP availability ranges themselves. I think you were already developing something like that in [1]<br></div><div>- Considering an alternative to availability ranges. Pre-generation of IP entries is unpractical (think IPv6), so that's not an option. Unfortunately, I have not yet explored in detail this route.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/100963/32/neutron/db/db_base_plugin_v2.py">https://review.openstack.org/#/c/100963/32/neutron/db/db_base_plugin_v2.py</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">
<br>
cheers,<br>
<br>
Rossella<br>
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/149261/" target="_blank">https://review.openstack.org/#/c/149261/</a><br>
<br>
__________________________________________________________________________<br>
<span class="">OpenStack Development Mailing List (not for usage questions)<br>
</span>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><br></div></div>