Open Stack

I started to type the same response as Duncan last night, and I do have
the same concern.

The fine grained quotas in nova, for instance, can be used to measure
potential use of the whole system _exactly_. You can give a bit more
to one tenant while you're building out your infrastructure for more
tenants to come on board at the lower quotas and know that the one more
demanding tenant will still be happy.

But how much RAM does it cost to have 1000 stacks creating all at
once? How much CPU does it cost? Those are not really 1:1 correlated,
and so I also question whether one can really use these quotas to do
such fine grained planning.

Excerpts from Duncan Thomas's message of 2014-06-20 05:12:44 -0700:
> There's a maintenance and testing cost to the added complexity, and as
> far as I can tell, no solid use-case. Under what circumstance would a
> cloud provider want different limits for different tenants? What
> concrete problem does it solve?
> 
> On 20 June 2014 04:35, Huangtianhua <huangtianhua at huawei.com> wrote:
> > Hi, Clint,
> >
> > Thank you for your comments on my BP and code!
> >
> > The BP I proposed is all about putting dynamic, admin-configurable limitations
> > on stack number per tenant and stack complexity. Therefore, you can consider my BP as
> > an extension to your config file-based limitation mechanism. If the admin does not want to
> > configure fined-grained, tenant-specific limits, the values in config become the defalut
> > values of those limits.
> >
> > And just like only an Admin can config the limit items in the config file, the limit update
> > and delete APIs I proposed are also Admin-only. Therefore, users can not set those values by
> > themselves to break the anti-DoS capability you mentioned.
> >
> > The reason I want to introduce the APIs and the dynamic configurable capability to those
> > limits mainly lies in that, since various tenants have various underlying resource quota,
> > and even various template/stack complexity requirements, I think a global, static-configured
> > limitation mechanism could be refined to echo user requirements better.
> >
> > Your idea?
> >
> > By the way, I do think that, the DoS problem is interesting in Heat. Can we have more discussion on that?
> >
> > Thanks again!
> >
> > -----邮件原件-----
> > 发件人: Clint Byrum [mailto:clint at fewbar.com]
> > 发送时间: 2014年6月20日 6:33
> > 收件人: openstack-dev
> > 主题: Re: [openstack-dev] [Heat] fine grained quotas
> >
> > Excerpts from Randall Burt's message of 2014-06-19 15:21:14 -0700:
> >> 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.
> >
> > Far be it from any of us to dictate a single business model. However, Heat is a tool which encourages consumption of billable resources by making it easier to tie them together. This is why FedEx gives away envelopes and will come pick up your packages for free.
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>