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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
