Open Stack

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 <priteau at 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 <zioproto at 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.morales at 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 at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170323/c23cdc39/attachment.html>