From: Salvatore Orlando <<>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
Date: Thursday, February 12, 2015 at 8:36 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [Neutron] Update on "DB" IPAM driver


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.

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:

- 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]

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.


- 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)

- 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).

- 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:
A) consider a strategy for running pluggable IPAM as optional
B) consider delaying to Liberty.
(and that's where I get virtually jeered and pelted with rotten tomatoes)

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.

Thanks for reading this post,

OpenStack Development Mailing List (not for usage questions)

Reply via email to