Open Stack

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20180313/1802026b/attachment-0001.sig>