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 <huangtian...@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:cl...@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 <cl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
