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.jer...@metaswitch.com> wrote: > Salvatore Orlando <sorla...@nicira.com> writes: > > > On 25 March 2015 at 17:36, Neil Jerram <neil.jer...@metaswitch.com> > > wrote: > > > > 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? > > > > > > > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
__________________________________________________________________________ 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
