On Wed, 2015-12-16 at 20:35 +0000, Adrian Otto wrote: > Clint, > > > On Dec 16, 2015, at 11:56 AM, Tim Bell <tim.b...@cern.ch> wrote: > > > > > -----Original Message----- > > > From: Clint Byrum [mailto:cl...@fewbar.com] > > > Sent: 15 December 2015 22:40 > > > To: openstack-dev <openstack-dev@lists.openstack.org> > > > 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. 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
