Kevin Benton <blak...@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
__________________________________________________________________________
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
