<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 10:09 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> writes:<br>
<br>
> On 25 March 2015 at 17:36, Neil Jerram <<a href="mailto:Neil.Jerram@metaswitch.com">Neil.Jerram@metaswitch.com</a>><br>
> wrote:<br>
><br>
>     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<br>
>     the<br>
>     > complexity of NAT. From a custom L3 plugin perspective, it also<br>
>     > eliminated any single points of failure pretty easily since no<br>
>     NAT<br>
>     > state had to be distributed.<br>
>     ><br>
>     > However, it was difficult to use with tenant self-service since<br>
>     one<br>
>     > tenant could create a subnet that ate up the whole routing<br>
>     space. It<br>
>     > basically required that the networking was done by an admin or<br>
>     that<br>
>     > the entire deployment was shared by a group of users trusted to<br>
>     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<br>
>     tenant<br>
>     > subnet allocation from a subnet pool shared by the whole<br>
>     deployment, I<br>
>     > think deprecation of the "allow_overlapping_ips" option makes<br>
>     perfect<br>
>     > sense since the operator can just create a single global subnet<br>
>     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<br>
>     that<br>
>     covers tenant subnet allocation from a subnet pool shared by the<br>
>     whole<br>
>     deployment" and "the operator [creates] a single global subnet<br>
>     pool",<br>
>     what will prevent a tenant from allocating a very large subnet of<br>
>     that<br>
>     address space?<br>
><br>
><br>
><br>
> For this specific item - shared subnet pools come with a quota<br>
> mechanism, which ensure each tenant won't get more than a given share<br>
> of the pool.<br>
> This mechanism is still under review [1], we hope to be able to<br>
> complete the review for the Kilo release.<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/165264/" target="_blank">https://review.openstack.org/#/c/165264/</a><br>
<br>
</div></div>Ah, so the new allocation_quota is an important factor here too.  Many<br>
thanks for explaining that!<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>