We run a similar kind of script. 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.
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. 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*. On Thu, Mar 23, 2017 at 5:46 PM, Pierre Riteau <prit...@uchicago.edu> wrote: > 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. > > You may be interested by this OSOps script: https://git.openstack.org/ > cgit/openstack/osops-tools-generic/tree/neutron/orphan_tool/delete_orphan_ > floatingips.py > 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. > > 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. > 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. > > Ideally Neutron would be able to track when a floating IP was last > attached and release it automatically after a configurable period of time. > > > On 23 Mar 2017, at 12:47, Saverio Proto <ziopr...@gmail.com> wrote: > > > > Hello, > > > > floating IPs is the real issue. > > > > When using horizon it is very easy for users to allocate floating ips > > but it is also very difficult to release them. > > > > In our production cloud we had to change the default from 50 to 2. We > > have to be very conservative with floatingips quota because our > > experience is that the user will never release a floating IP. > > > > A good starting point is to set the quota for the floatingips at the > > the same quota for nova instances. > > > > Saverio > > > > > > 2017-03-22 16:46 GMT+01:00 Morales, Victor <victor.mora...@intel.com>: > >> Hey there, > >> > >> > >> > >> I noticed that Ihar started working on a change to increase the default > >> quotas values in Neutron[1]. Personally, I think that makes sense to > change > >> it but I’d like to complement it. So, based on your experience, what > should > >> be the most common quota value for networks, subnets, ports, security > >> groups, security rules, routers and Floating IPs per tenant? > >> > >> > >> > >> Regards/Saludos > >> > >> Victor Morales > >> > >> irc: electrocucaracha > >> > >> > >> > >> [1] https://review.openstack.org/#/c/444030 > >> > >> > >> _______________________________________________ > >> OpenStack-operators mailing list > >> OpenStack-operators@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >> > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
