Open Stack

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/


> Thanks,
>         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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150325/3d0f8863/attachment.html>