Open Stack

On Tue, 13 Mar 2018 at 19:36, Tim Bell <Tim.Bell at cern.ch> wrote:

> Lance,
>
> Thanks for reaching out. BTW, we're not set on how hierarchical quotas
> should work but we were trying to write down a possible scenario. There was
> also quite a lot of interest from other labs so I'm adding the Scientific
> SIG to the thread.
>
> We also expanded a little on the approach in
> http://openstack-in-production.blogspot.fr/2017/07/nested-quota-models.html
> based on some discussions with Sean where he was looking for more detail.
>

I had forgotton about that blog, thanks for reminding me.

My current proposal is really going for something as simple as possible
that unblocks a bunch of use cases in a way that we can discover what might
need building next:
https://review.openstack.org/#/c/549766/

It limits the hierarchy to two levels for coding (and operational)
simplicity. I was thinking of the community / virtual organisation model
(VOMS/EGI AAI), where the community gets an amount of quota. That community
is then allowed one level of sub projects that can also use some resources
from the pool of quota given to the whole community. Given you must count
how many resources are owned by all projects in the tree, there is a strong
argument towards keeping the tree as small as possible.

I am particularly interested in the use cases that are really blocked with
only two levels of hierarchy.

Thanks,
John

-----Original Message-----
> From: Lance Bragstad <lbragstad at gmail.com>
> Date: Tuesday, 13 March 2018 at 20:25
> To: "user-committee at lists.openstack.org" <
> user-committee at lists.openstack.org>
> Subject: [User-committee] Unified limits and hierarchical project use cases
>
>     Hey all,
>
>     Unified limits and hierarchical quotas was a big topic during the Rocky
>     PTG. With the ground work laid in Queens, most of the discussions for
>     Rocky focused on different enforcement models.
>
>     For those who haven't been keeping up with the unified limits
>     discussions, an enforcement model is an opinionated way of how a quota,
>     or limit, should behave with respect to other parent, sibling, or child
>     projects. It's possible to think of multiple ways in which enforcement
>     can be done, and it's not that there is one right way and the rest are
>     wrong, just a difference in how quotas might need to behave for
>     different deployments.
>
>     During the discussions at the PTG, everyone in the room agreed that we
>     don't really understand how people are using hierarchical projects.
> This
>     makes it tough to design a quota or limit enforcement model without
>     understanding how people expect it to work. Tim Bell has taken some
> time
>     to write down how he expects a quota system to work for CERN's use case
>     [0], which we'll be working into a specification for an enforcement
>     model [1].
>
>     We'd like to see if the User Committee can help us collect more
>     information from users and operators about how they expect enforcement
>     to be done. Do your deployments use hierarchical projects? How do you
>     manage quota today? Do you have expectations about how quotas and
> limits
>     work across related projects (e.g. setting quota on a parent project
>     affects the children in X ways)?
>
>     Depending on responses, it'd be nice to aggregate the results, kind of
>     like what Tim provided, so that we can write a specification for them.
>
>     Is there a way we can leverage the UC to collect this information?
>
>     Thanks,
>
>     Lance
>
>     [0]
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-February/111999.html
>     [1] https://review.openstack.org/#/c/549766/
>
>
>
> _______________________________________________
> openstack-sigs mailing list
> openstack-sigs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20180313/d8fee7f8/attachment.html>