Open Stack

On 09/05/16 12:36, Sylvernass Arthas wrote:
> Excerpts from Sylvernass Arthas's message of 2016-05-08 05:33:13 -0700:
>
>> Hi, guys
>
>>
>
>>   Now, all tenant share the public config "max_stacks_per_tenant" which decides maximum number of stacks any one tenant may have active at one time, the default value is 1000.
>
>> Should heat provides ability to set this config by different tenant? For example, in a enterprise, maybe tenant A needs 10000 stack quota, tenant B needs 100 stack quota, but now heat can't manage with it, at least  in Liberity.

The response below was correct; the idea has never been to allow tenants 
to limit their billable resource use (since most clouds don't bill for 
orchestration), it was always about not crashing Heat.

Simply put, there's not much point in giving tenant A permission to 
create 10000 stacks if it will make Heat fall over (it depends how they 
use them, of course). And there's even less point in limiting tenant B 
to 100 stacks - you should worry about the things (like Nova servers) 
that tenant B is creating in those stacks and limit _those_ with quotas.

>>   So in future, will heat provides this ability or other policy to solve this?
>
> I think enough people have stated that they want it that it will happen
> some day. There may even be a spec now, I haven't been tracking all of
> the specs. However, I don't actually think there's any point to Heat
> quotas, as the resources used to run a Heat stack are so much cheaper
> compared to the resources it enables the user to consume -- servers,
> networks, volumes, etc. One might as well let users run as many heat
> stacks as they want within reason, as their quotas on those items will
> fill up far before they cost you any actual money.
>
> In fact, the only reason the max setting exists now is to protect the
> code that does stack listing from eating up all of the memory on the
> servers.

Not just that code, but any code in general. I think the biggest concern 
was that someone could create a very large tree of nested stacks with 
the result that it would eat up all the memory on the box, back in the 
days when each tree of stacks ran on a single box. That's mitigated 
somewhat from Kilo on, since if you run into this problem now we can say 
that you can prevent it by scaling out to more heat-engines rather than 
giving them more RAM to play with.

> It has a second unintended use case which is to prevent anyone from
> using Heat as free object storage. :)
>
> It's important to take my words with a grain of salt. I'm not directly
> involved with Heat anymore.

Right on the money.

cheers,
Zane.