Open Stack

On Wed, 2015-12-16 at 20:35 +0000, Adrian Otto wrote:
> Clint,
> 
> > On Dec 16, 2015, at 11:56 AM, Tim Bell <tim.bell at cern.ch> wrote:
> > 
> > > -----Original Message-----
> > > From: Clint Byrum [mailto:clint at fewbar.com]
> > > Sent: 15 December 2015 22:40
> > > To: openstack-dev <openstack-dev at 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.