Open Stack

Yes, sorry I should have specified that. Salvatore is right that this
depends on the quota mechanism to prevent them from exhausting the entire
pool.

On Wed, Mar 25, 2015 at 10:09 AM, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> 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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150325/a0493446/attachment.html>