On 13 February 2015 at 12:40, Rossella Sblendido <rsblend...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
