<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 25 March 2015 at 17:36, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> writes:<br>
<br>
> This is a nice option for smaller deployments that didn't need the<br>
> complexity of NAT. From a custom L3 plugin perspective, it also<br>
> eliminated any single points of failure pretty easily since no NAT<br>
> state had to be distributed.<br>
><br>
> However, it was difficult to use with tenant self-service since one<br>
> tenant could create a subnet that ate up the whole routing space. It<br>
> basically required that the networking was done by an admin or that<br>
> the entire deployment was shared by a group of users trusted to do the<br>
> right thing.<br>
><br>
> My main interest in the IPAM work was to support fully routable<br>
> deployments like this. Once IPAM has a workflow that covers tenant<br>
> subnet allocation from a subnet pool shared by the whole deployment, I<br>
> think deprecation of the "allow_overlapping_ips" option makes perfect<br>
> sense since the operator can just create a single global subnet pool<br>
> to simulate it.<br>
<br>
I'm not defending allow_overlapping_ips, but I'm afraid I don't<br>
understand your point.  In the future where "IPAM has a workflow that<br>
covers tenant subnet allocation from a subnet pool shared by the whole<br>
deployment" and "the operator [creates] a single global subnet pool",<br>
what will prevent a tenant from allocating a very large subnet of that<br>
address space?<br>
<br></blockquote><div><br></div><div>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.</div><div>This mechanism is still under review [1], we hope to be able to complete the review for the Kilo release.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/165264/">https://review.openstack.org/#/c/165264/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks,<br>
        Neil<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>