Open Stack

Kevin Benton <blak111 at gmail.com> writes:

> This is a nice option for smaller deployments that didn't need the
> complexity of NAT. From a custom L3 plugin perspective, it also
> eliminated any single points of failure pretty easily since no NAT
> state had to be distributed. 
>
> However, it was difficult to use with tenant self-service since one
> tenant could create a subnet that ate up the whole routing space. It
> basically required that the networking was done by an admin or that
> the entire deployment was shared by a group of users trusted to do the
> right thing.
>
> My main interest in the IPAM work was to support fully routable
> deployments like this. Once IPAM has a workflow that covers tenant
> subnet allocation from a subnet pool shared by the whole deployment, I
> think deprecation of the "allow_overlapping_ips" option makes perfect
> sense since the operator can just create a single global subnet pool
> to simulate it.

I'm not defending allow_overlapping_ips, but I'm afraid I don't
understand your point.  In the future where "IPAM has a workflow that
covers tenant subnet allocation from a subnet pool shared by the whole
deployment" and "the operator [creates] a single global subnet pool",
what will prevent a tenant from allocating a very large subnet of that
address space?

Thanks,
        Neil