Open Stack

On Wed, 16 Mar 2016, Salvatore Orlando wrote:

> - Looking at quotas it is worth distinguishing between management (eg::
> resource limits per tenant and/or users), and enforcement (eg.: can the
> bakery service give me 4 cookies or did I already eat too many?)
>  While for the reasons listed throughout this thread the latter should
> really happen in the same context where the request is going to served,
> quota management instead might be its own service, or however being done in
> a common endpoint for all OpenStack resources.

Thanks. I've been reading through this thread getting increasingly
confused. The proposed openstack-spec[1] does a pretty good job of
keeping management and enforcement separate but this thread, it's
not too clear. So somebody help me out, is the following in the
realm of right?

As stated by a few other people, enforcement is in the domain of
authZ: entity X has a "quota", or is a member of something that has
a "quota". Does their request + their existing use fit within that
quota? No, sorry, computer says no. That quota could be a fairly static
statement of a limit, however the information that needs to be expressed
there is probably complex.

The accounting of "their existing use" is the hard part, right? It is
also a generic problem we have in much of OpenStack:

* how much stuff is there?
* how much of it is used?
* who/what has used it?

Quota enforcement needs that information, schedulers/placers needs that
information. If that information were available as a service,
everybody would find it helpful.

If there are going to be services, there are two of them:

* accounting
* quota enforcement

Is that right?

> - It has also been raised a good point about securing a chunk of resources
> across project, that is also related to John's point about business
> quotas... I'm not sure it is necessary, but Blazar [1] kind of achieves
> this - even if it was conceived with different purposes.

I believe this is described as 'reservations' in the spec and I
agree with John Garbutt that it greatly raises the complexity. If we
have a system where we're having to do claims, instead of just
reflecting reality (i.e. real usage), things will go wrong, quickly.

We're much better figuring out a simpler system that includes the
possibility to fail fast.

[1] The proposed spec: https://review.openstack.org/#/c/284454/

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent