Salvatore Orlando <[email protected]> writes:
> On 25 March 2015 at 17:36, Neil Jerram <[email protected]>
> wrote:
>
> Kevin Benton <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
