OpenStack Heat

100 stacks per tenant limit should be a quota

Bug #1391898 reported by Pierre Freund
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Won't Fix
Undecided
Unassigned

Bug Description

My Heat usecase is a (very) big marketplace for endusers. Users will create stacks when subscribing to offers (bitnami style, but not only an image, a full template with other resources than a nova server).

I am limited with many quotas in other services, but I can change them using quota updates commands for my "super tenant".

I encountered an issue with the heat 100 stacks/tenant limit. I will launch much more than 100 stacks.
This limit is hardcoded in heat's configuration and should not be. I should be able to change it like any other quota in OpenStack.

Another subject is, why keeping quotas in heat ? Other services have already quotas.
For templates not using any other service (like a template only generating random strings), maybe heat should have a limitation, but it has to be a quota.

See original description
Pierre Freund (pierre-freund)
description: updated
Pierre Freund (pierre-freund)
summary: - 100 stack per tenant limit should be a quota
+ 100 stacks per tenant limit should be a quota
Revision history for this message
Ethan Lynn (ethanlynn) wrote :

There is a option max_stacks_per_tenant can be config in heat.conf.
https://github.com/openstack/heat/blob/master/etc/heat/heat.conf.sample#L49

Revision history for this message
Hrushikesh (hrushikesh-gangur) wrote :

https://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat - this should address

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

I've said this on many occasions, so I'll say it again here just to make sure my belief is understood.

Quotas are for consumption of real resources that one can actually be charged for. The static limitations we have currently are implementation details to handle things like 'stack-list', which will consume a lot of memory and CPU in the engine that serves it, and in the database query that it runs. This is not the same as a nova quota or swift quota.

The ratio of cost for actual billable resources to heat-only resources like random string generators is infinitesimal. You can probably create a million random string generators and a Heat engine will go to stack complete in just a few seconds, most of that the momentary database churn while we update a million rows to CREATE_COMPLETE. One nova server though, will consume that memory and CPU for its life time.

I can see where there are enough people who think quotas should be there, that it's probably moot, and users should just be given what they want. I do not think the cost (complexity) is worth the obvious benefit (limitations on extremely cheap resources). However, if we also retain users because they're happier having an API for limiting users, then that is a benefit worth far more than the complexity.

Angus Salkeld (asalkeld)
Changed in heat:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.