Open Stack

I must have archived this on accident.  Sorry to not respond earlier.
Comments inline...

On Feb 12, 2015 6:40 AM, "Salvatore Orlando" <sorlando at nicira.com> wrote:
> 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 hope to look at it soon.  Thanks for your work here.

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

We missed you.

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

Good point.

> - 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 like this.  It is how I was leaning too.

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

Hmm.  Didn't see that coming.

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

Looking at Pavel's code, it appears it is optional in its current state.
It seems to leave all of the existing code in place.  The if/then/else
statements make me want to pull my hair out but if it is just a temporary
strategy to mitigate risk them I guess I could tolerate it until Liberty.

> B) consider delaying to Liberty.
> (and that's where I get virtually jeered and pelted with rotten tomatoes)

I think we still have time maybe with risk mitigation from A.  I'm not
ready to give up yet!

Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150214/57e56d2e/attachment.html>