Open Stack

Excerpts from Adrian Otto's message of 2015-12-16 12:35:10 -0800:
> 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. 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.
> 

I'm agreeing that users need limits of course. The implementation has a
capacity, and those limitations will be quickly found by any unlimited
user.

What I'm suggesting is that those limitations be the same for every user,
and that their billing would be the limit that stops them from doing
more than they can afford _way_ before they can really break Magnum. This
will make the service more of a force-multiplier for the real services,
and thus drive as much spending toward using your cloud, which is the
actual goal.

I think of things like Heat and Magnum like freeways. They cost an order
of magnitude less to maintain than the benefit they have on the economy as
a whole. So, have weight limits (per-request sanity checks) , set speed
limits (per-user global limit), meter the onramps during busy periods
(rate limiting), etc. But you wouldn't require every user of the freeway
to prove that it didn't have too many cars on the freeway right now before
letting it get on. The expense of doing that, and the complexity of it,
would make it untenable in any useful way. The users of this piece of
infrastructure are already limited enough by the actual cost of the cars,
cargo, commerce, or on the cloud, the disk/cpu/mem/network.

So I'm suggesting that you should not be tuning things up and down per
user, but testing the true safe limits of what your service can do,
and configuring it to do that in aggregate, which is _far_ simpler.