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