Open Stack

On 13 February 2015 at 12:40, Rossella Sblendido <rsblendido at suse.com>
wrote:

>
>
> On 02/12/2015 02:36 PM, Salvatore Orlando wrote:
> > - 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).
>
> Would something like the following work: insert the data in the DB, if
> any error is got open a new transaction and try again ? enikanorov
> proposed a retry mechanism here [1] . Can't wait for your POC! I had
> been playing a while in the past to try to remove the locking from the
> IP allocation, it's hard!
>

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.
As a matter of fact, we're indeed splitting the IPAM transaction from the
transaction which creates or updates the port.
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.
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:
- 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.
- 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]
- 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.

Salvatore


[1]
https://review.openstack.org/#/c/100963/32/neutron/db/db_base_plugin_v2.py

>
> cheers,
>
> Rossella
>
>
> [1] https://review.openstack.org/#/c/149261/
>
> __________________________________________________________________________
> 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/20150213/774aaf1e/attachment.html>