On one cloud, I had to allow lots of other projects the ability to create way too many stacks, just to allow the one that owned a lot of dedicated hypervisors the ability to launch stacks on their own hardware. The default was reasonable for most, but not all users. One value can't rule them all.
Another case to consider is multiple regions. We're starting to support them in places, and have set all the default quota's we can to 0 on everything. Why? We want the ability to add projects to our shared keystone, and then set the quota's in a particular region for the project to allow them on. This allows an operator to restrict which regions a project can use. If there was only a single value, it must be set !=0, and then users could do stuff on regions they shouldn't. You could work around this with policy changes, making whole parallel sets of roles and tweaking a ton of policy files, but that's much worse I think then tweaking some quotas on a project. There are a lot of other places where there aren't enough quota's. Nova availability zones for example. Say you have two sets of hardware. Those with ups's and those not on ups. Say you have 10x the number of nonupsed nodes and want to allow users to use some of each. Nova today can only quota instances. Meaning, if you give them enough quota to reasonably use the nonups'ed hardware, they can consume way more of the upsed then you might want. This seems totally unrelated, but I mention it because the lack of quotas do affect what services an operator can provide. That should be carefully considered. There are lots of other examples of this too. Thanks, Kevin ________________________________________ From: Clint Byrum [[email protected]] Sent: Wednesday, December 16, 2015 4:21 PM To: openstack-dev Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources Excerpts from Fox, Kevin M's message of 2015-12-16 16:05:29 -0800: > Yeah, as an op, I've run into a few things that need quota's that just have > basically hardcoded values. heat stacks for example. its a single global in > /etc/heat/heat.conf:max_stacks_per_tenant=100. Instead of being able to tweak > it for just our one project that legitimately has to create over 200 stacks, > I had to set it cloud wide and I had to bounce services to do it. Please > don't do that. > > Ideally, it would be nice if the quota stuff could be pulled out into its own > shared lib (oslo?) and shared amongst projects so that they don't have to > spend much effort implementing quota's. Maybe then things that need quota's > that don't currently can more easily get them. > You had to change a config value, once, and that's worse than the added code complexity and server load that would come from tracking quotas for a distributed service? __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
