On 03/08/2017 04:14 PM, Sean Dague wrote:
On 03/08/2017 07:12 AM, Tim Bell wrote:
On 7 Mar 2017, at 11:52, Sean Dague <[email protected]> wrote:
One of the things that came out of the PTG was perhaps a new path
forward on hierarchical limits that involves storing of limits in
keystone doing counting on the projects. Members of the developer
community are working through all that right now, that's not really what
this is about.
As a related issue, it seemed that every time that we talk about this
space, people jump into describing how they think the counting /
enforcement would work. It became clear that people were overusing the
word "overbooking" to the point where it didn't have a lot of meaning.
https://review.openstack.org/#/c/441203/ is a reference document that I
started in writing out every model I thought I heard people talk about,
the rules with it, and starting to walk through the kind of algorithm
needed to update limits, as well as check quota on ones that seem like
we might move forward with.
It is full of blockdiag markup, which makes the rendered HTML the best
way to view it -
http://docs-draft.openstack.org/03/441203/11/check/gate-keystone-specs-docs-ubuntu-xenial/c3fc2b3//doc/build/html/specs/keystone/backlog/hierarchical-quota-scenarios.html
There are specific question to the operator community here:
Are there other models you believe are not represented that you think
should be considered? if so, what are the rules of them so I can throw
them into the document.
Thanks. In the interest of completeness, I’ll add one more scenario
to the mix but I would not look for this as part of the functionality
of the 1st release.
One item we have encountered in the past is how to reduce quota for
projects. If a child project quota is to be reduced but it is running
the maximum number of VMs, the parent project administrator has to
wait for the child to do the deletion before they can reduce the
quota. Being able to do this would mean that new resource creation
would be blocked but that existing resources would continue to run
(until the child project admin gets round to choosing the priorities
for deletion out of the many VMs he has running)
However, this does bring in significant additional complexity so
unless there is an easy way of modelling it, I’d suggest this for
nested quotes v2 at the earliest.
Actually.... if we unify limit definitions to keystone, that's going to
be the default behavior. A change in limits *will not* validate against
existing usage. That will get called out more specifically in the next
version of the unified limits spec.
++
-jay
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
