Open Stack

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