<div dir="ltr"><div><div>We run a similar kind of script.<br><br></div>I think in most cases, a Floating IP means a publicly routable IP, and those are now scarce resources. Because of that, I agree with what's been mentioned about a conservative floating IP quota.<br><br>Since the other resource types aren't restricted by external availability, they could easily be a higher value. Of course, a small floating IP quota might restrict what a user can do with the other resources. <br><br></div><div>The only network resource I've had a user request an increase on is security groups and rules. Users manage security groups and rules in a lot of different ways. Some are very conservative and some make new groups for *everything*. <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 23, 2017 at 5:46 PM, Pierre Riteau <span dir="ltr"><<a href="mailto:priteau@uchicago.edu" target="_blank">priteau@uchicago.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We’ve encountered the same issue in our cloud. I wouldn’t be surprised if it was quite common for systems with many tenants that are not active all the time.<br>
<br>
You may be interested by this OSOps script: <a href="https://git.openstack.org/cgit/openstack/osops-tools-generic/tree/neutron/orphan_tool/delete_orphan_floatingips.py" rel="noreferrer" target="_blank">https://git.openstack.org/<wbr>cgit/openstack/osops-tools-<wbr>generic/tree/neutron/orphan_<wbr>tool/delete_orphan_<wbr>floatingips.py</a><br>
The downside with this script is that it may delete a floating IP that was just allocated, if it runs just before the user attaches it to their instance.<br>
<br>
We have chosen to write a script that releases floating IPs held by tenants only if the tenant is inactive for a period of time. We define inactive by not having run any instance during this period.<br>
It is not a silver bullet though, because a tenant running only one instance can still keep 49 floating IPs unused, but we found that it helps a lot because most of the unused IPs were held by inactive tenants.<br>
<br>
Ideally Neutron would be able to track when a floating IP was last attached and release it automatically after a configurable period of time.<br>
<br>
> On 23 Mar 2017, at 12:47, Saverio Proto <<a href="mailto:zioproto@gmail.com">zioproto@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> floating IPs is the real issue.<br>
><br>
> When using horizon it is very easy for users to allocate floating ips<br>
> but it is also very difficult to release them.<br>
><br>
> In our production cloud we had to change the default from 50 to 2. We<br>
> have to be very conservative with floatingips quota because our<br>
> experience is that the user will never release a floating IP.<br>
><br>
> A good starting point is to set the quota for the floatingips at the<br>
> the same quota for nova instances.<br>
><br>
> Saverio<br>
><br>
><br>
> 2017-03-22 16:46 GMT+01:00 Morales, Victor <<a href="mailto:victor.morales@intel.com">victor.morales@intel.com</a>>:<br>
>> Hey there,<br>
>><br>
>><br>
>><br>
>> I noticed that Ihar started working on a change to increase the default<br>
>> quotas values in Neutron[1].  Personally, I think that makes sense to change<br>
>> it but I’d like to complement it.  So, based on your experience, what should<br>
>> be the most common quota value for networks, subnets, ports, security<br>
>> groups, security rules, routers and Floating IPs per tenant?<br>
>><br>
>><br>
>><br>
>> Regards/Saludos<br>
>><br>
>> Victor Morales<br>
>><br>
>> irc: electrocucaracha<br>
>><br>
>><br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/444030" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/444030</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> OpenStack-operators mailing list<br>
>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
>><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div><br></div>