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/ > Thanks, > 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 >
__________________________________________________________________________ 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