[openstack-dev] Hierarchical quotas at the PTG?

Tim Bell Tim.Bell at cern.ch
Sun Feb 12 18:53:07 UTC 2017


On 12 Feb 2017, at 12:13, Boris Bobrov <bbobrov at mirantis.com<mailto:bbobrov at mirantis.com>> wrote:

I would like to talk about it too.

On 02/10/2017 11:56 PM, Matt Riedemann wrote:
Operators want hierarchical quotas [1]. Nova doesn't have them yet and
we've been hesitant to invest scarce developer resources in them since
we've heard that the implementation for hierarchical quotas in Cinder
has some issues. But it's unclear to some (at least me) what those
issues are.

I don't know what the actual issue is, but from from keystone POV
the issue is that it basically replicates project tree that is stored
in keystone. On top of usual replication issues, there is another one --
it requires too many permissions. Basically, it requires service user
to be cloud admin.

I have not closely followed the cinder implementation since the CERN and BARC Mumbai focus has more around Nova.

The various feedbacks I have had was regarding how to handle overcommit on the cinder proposal. A significant share of the operator community would like to allow

- No overcommit for the ‘top level’ project (i.e. you can’t use more than you are allocated)]
- Sub project over commit is OK (i.e. promising your sub projects more is OK, sum of the commitment to subprojects>project is OK but should be given an error if it actually happens)



Has anyone already planned on talking about hierarchical quotas at the
PTG, like the architecture work group?

I know there was a bunch of razzle dazzle before the Austin summit about
quotas, but I have no idea what any of that led to. Is there still a
group working on that and can provide some guidance here?

In my opinion, projects should not re-implements quotas every time.
I would like to have a common library for enforcing quotas (usages)
and a service for storing quotas (limits). We should also think of a
way to transfer necessary projects subtree from keystone to quota
enforcer.

We could store quota limits in keystone and distribute it in token
body, for example. Here is a POC that we did some time ago --
https://review.openstack.org/#/c/403588/ and
https://review.openstack.org/#/c/391072/
But it still has the issue with permissions.


There has been an extended discussion since the Boson proposal at the Hong Kong summit on how to handle quotas, where a full quota service was proposed.

A number of ideas have emerged since then

- Quota limits stored in Keystone with the project data
- An oslo library to support checking that a resource request would be OK

One Forum session at the summit is due to be on this topic.

Some of the academic use cases are described in https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html but commercial reseller models are valid here where

- company A has valuable resources to re-sell (e.g. flood risk and associated models)
- company B signs an agreement with Company A (e.g. an insurance company wants to use flood risk data as factor in their cost models)

The natural way of delivering this is that ‘A’ gives a pricing model based on ‘B’’s consumption of compute and storage resources.

Tim



[1]
http://lists.openstack.org/pipermail/openstack-operators/2017-January/012450.html



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170212/8acc3c87/attachment.html>


More information about the OpenStack-dev mailing list