Open Stack

John,

Two levels would certainly solve the vast majority of our use cases (i.e. delegation to a VO/Experiment within an envelope). The CERN blog included the expansion to 3 in that there had been some concerns from potential implementers raised over the algorithms when the nesting went beyond 2. Replacing the per user use case and moving resource ownership to the project would also simplify code in other areas.

Tim

From: John Garbutt <john at johngarbutt.com>
Date: Tuesday, 13 March 2018 at 22:08
To: "openstack-sigs at lists.openstack.org" <openstack-sigs at lists.openstack.org>
Cc: "user-committee at lists.openstack.org" <user-committee at lists.openstack.org>
Subject: Re: [User-committee] [Openstack-sigs] [Scientific] Unified limits and hierarchical project use cases

On Tue, 13 Mar 2018 at 19:36, Tim Bell <Tim.Bell at cern.ch<mailto: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<mailto:lbragstad at gmail.com>>
Date: Tuesday, 13 March 2018 at 20:25
To: "user-committee at lists.openstack.org<mailto:user-committee at lists.openstack.org>" <user-committee at lists.openstack.org<mailto: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<mailto: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/b318025d/attachment-0001.html>