[openstack-dev] [openstack][magnum] Quota for Magnum Resources

Fox, Kevin M Kevin.Fox at pnnl.gov
Thu Dec 17 00:54:06 UTC 2015

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.

From: Clint Byrum [clint at fewbar.com]
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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list