[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