[Openstack-sigs] [User-committee] [Scientific] Unified limits and hierarchical project use cases

Melvin Hillsman mrhillsman at gmail.com
Tue Mar 13 21:27:13 UTC 2018


Hey Lance,

Thanks for putting this on our radar. Personally I need to read Tim's blog
and understand a bit more about what this is exactly. I do remember a
thread last year that got a lot of responses of which hierarchical quotas[0]

[0]
http://lists.openstack.org/pipermail/openstack-operators/2017-January/012436.html

On Tue, Mar 13, 2018 at 4:07 PM, John Garbutt <john at johngarbutt.com> wrote:

> 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
>>
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20180313/a43604f0/attachment.html>


More information about the openstack-sigs mailing list