On Dec 16, 2015, at 2:25 PM, James Bottomley <[email protected]<mailto:[email protected]>> wrote:
On Wed, 2015-12-16 at 20:35 +0000, Adrian Otto wrote: Clint, On Dec 16, 2015, at 11:56 AM, Tim Bell <[email protected]<mailto:[email protected]>> wrote: -----Original Message----- From: Clint Byrum [mailto:[email protected]] Sent: 15 December 2015 22:40 To: openstack-dev <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [openstack][magnum] Quota for Magnum Resources Hi! Can I offer a counter point? Quotas are for _real_ resources. No. Beyond billable resources, quotas are a mechanism for limiting abusive use patterns from hostile users. Actually, I believe this is the wrong way to look at it. You're confusing policy and mechanism. Quotas are policy on resources. The mechanisms by which you implement quotas can also be used to limit abuse by hostile users, but that doesn't mean that this limitation should be part of the quota policy. I’m not convinced. Cloud operators already use quotas as a mechanism for limiting abuse (intentional or accidental). They can be configured with a system wide default, and can be set to a different value on a per-tenant basis. It would be silly to have a second mechanism for doing the same thing we already use quotas for. Quotas/limits can also be queried by a user so they can determine why they are getting a 4XX Rate Limit responses when they try to act on resources too rapidly. The idea of hard coding system wide limits into the system is making my stomach turn. If you wanted to change the limit you’d need to edit the production system’s configuration, and restart the API services. Yuck! That’s why we put quotas/limits into OpenStack to begin with, so that we had a sensible, visible, account-level configurable place to configure limits. Adrian For instance, in Linux, the memory limit policy is implemented by the memgc. The user usually sees a single figure for "memory" but inside the cgroup, that memory is split into user and kernel. Kernel memory limiting prevents things like fork bombs because you run out of your kernel memory limit creating task structures before you can bring down the host system. However, we don't usually expose the kernel/user split or the fact that the kmem limit mechanism can prevent fork and inode bombs. James The rate at which Bays are created, and how many of them you can have in total are important limits to put in the hands of cloud operators. Each Bay contains a keypair, which takes resources to generate and securely distribute. Updates to and Deletion of bays causes a storm of activity in Heat, and even more activity in Nova. Cloud operators should have the ability to control the rate of activity by enforcing rate controls on Magnum resources before they become problematic further down in the control plane. Admission controls are best managed at the entrance to a system, not at the core.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
