Open Stack

On Thu, Jun 19, 2014 at 10:21:14PM +0000, Randall Burt wrote:
> On Jun 19, 2014, at 4:17 PM, Clint Byrum <clint at fewbar.com> wrote:
> 
> > I was made aware of the following blueprint today:
> > 
> > http://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat
> > http://review.openstack.org/#/c/96696/14
> > 
> > Before this goes much further.. I want to suggest that this work be
> > cancelled, even though the code looks excellent. The reason those limits
> > are in the config file is that these are not billable items and they
> > have a _tiny_ footprint in comparison to the physical resources they
> > will allocate in Nova/Cinder/Neutron/etc.
> > 
> > IMO we don't need fine grained quotas in Heat because everything the
> > user will create with these templates will cost them and have its own
> > quota system. The limits (which I added) are entirely to prevent a DoS
> > of the engine.
> 
> What's more, I don't think this is something we should expose via API other than to perhaps query what those quota values are. It is possible that some provider would want to bill on number of stacks, etc (I personally agree with Clint here), it seems that is something that could/should be handled external to Heat itself.

I do think we need a read API for the config file "absolute limits", which
is why I raised this a while back:

https://blueprints.launchpad.net/heat/+spec/limits-api

This has been implemented by Huangtianhua, on top of the quota series:

https://review.openstack.org/#/c/99589/

I agree more use-case discussion about the quota functionality would be
useful, so far the main arguments for the functionality I've heard are:

1. "Rally needs it" - I'm not yet clear exactly why, can anyone explain?
2. Other projects have this API

As has been highlighted, the second point may be of questionable relevance
due to the lack of a direct correlation between e.g the number of stacks
and the resources consumed.

This is related to another recent discussion, where replacing the nested
stack depth limit with a recursive resource count was discussed.  If we're
going to have quotas in heat, then personally I think just one limit which
is total number of resources (per tenant) would be a good starting point,
rather than making everything configurable, which could make things
confusing for users and operators.

Steve