Open Stack

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 <sean at dague.net> 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