Open Stack

Salvatore Orlando <sorlando at nicira.com> writes:

> On 25 March 2015 at 17:36, Neil Jerram <Neil.Jerram at metaswitch.com>
> wrote:
>
>     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?
>     
>     
>
> For this specific item - shared subnet pools come with a quota
> mechanism, which ensure each tenant won't get more than a given share
> of the pool.
> This mechanism is still under review [1], we hope to be able to
> complete the review for the Kilo release.
>
> [1] https://review.openstack.org/#/c/165264/

Ah, so the new allocation_quota is an important factor here too.  Many
thanks for explaining that!

    Neil