Open Stack

On 06/10/2016 12:24 PM, Carl Baldwin wrote:
> On Fri, Jun 10, 2016 at 2:40 AM, Gary Kotton <gkotton at vmware.com> wrote:
>> Hi,
>> The patch https://review.openstack.org/#/c/292207/ has broken decomposed
>> plugins. I am not sure if we can classify this as a API change – basically
>
> Can you be more specific about how it "has broken decomposed plugins?"
>   What's broken?  There are no links or anything.
>
>> the IP address allocation model has changed. So someone prior to the patch
>> could create a network and expect addresses A, B and C to be allocated in
>
> Nothing has ever been documented indicating that you can expect this.
> People just noticed a pattern and assumed they could count on it.
> Anyone depending on this has been depending on an implementation
> detail.  This has come up before [1].  I think we need flexibility to
> allocate IPs as we need to to scale well.  I don't think we should be
> restricted by defacto patterns in IP allocation that people have come
> to depend on.
>
> Any real world use should always take in to account the fact there
> there may be other users of the system trying to get IP allocations in
> parallel.  To them, the expected behavior doesn't change: they could
> get any address from a window of the next few available addresses.
> So, the problem here must be in tests running in a contrived setup
> making too many assumptions.
>
>> that order. Now random addresses will be allocated.
>
> After nearly 3 years of dealing with DB contention around IP
> allocation, this is the only way that we've been able to come up with
> to finally relieve it.  When IPAM gets busy, there is a lot of racing
> to get that next IP address which results in contention between worker
> processes.  Allocating from a random window relieves it considerably.
>
>> I think that this requires some discussion and we should consider reverting
>> the patch. Maybe I am missing something here but this may break people who
>> are working according the existing outputs of Neutron according to existing
>> behavior (which may have been wrong from the start).
>
> Some discussion was had [2][3] leading up to this change.  I didn't
> think we needed broader discussion because we've already established
> that IP allocation is an implementation detail [1].  The only contract
> in place for IP allocation is that an IP address will be allocated
> from within the allocation_pools defined on the subnet if available.
>
> I am against reverting this patch as I have stated on the review to
> revert it [4].

++ I, too, am against reverting it. If code was relying on a 
non-contractual assumption about the ordering of IP addresses, that code 
should be changed.

-jay