[Openstack-operators] [neutron] Modify Default Quotas
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
Re: [Openstack-operators] [neutron] Modify Default Quotas
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 : > 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
Re: [Openstack-operators] [neutron] Modify Default Quotas
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 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 : >> 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
Re: [Openstack-operators] [neutron] Modify Default Quotas
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 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 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 : > >> 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
