Re: [Openstack-operators] RFC - hierarchical quota models
On 03/08/2017 07:12 AM, Tim Bell wrote: On 7 Mar 2017, at 11:52, Sean Daguewrote: 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. -Sean -- Sean Dague http://dague.net ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Milano session on Fault Injection and Remediation.
Here the skeleton for the Session: https://etherpad.openstack.org/p/MIL-ops-fault-injection-and-remediation Please provide input/feedback, the intent is to cover anything related to Fault Management, Reliability and Fault Genes working group. Isaac. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Milano session on Upgrades Patches and Packaging
Hello, I prepared the skeleton for the session about Upgrades Patches and Packaging https://etherpad.openstack.org/p/MIL-ops-upgrades-patches-packaging Please contribute to the etherpad with stuff like: * patches that you are carrying in production * patches that you dont manage to get merged upstream * upgrade problems * regression bugs once you land on the new release This is a session that is very useful if you have to do soon an openstack upgrade :) ciao, Saverio ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] RFC - hierarchical quota models
> On 7 Mar 2017, at 11:52, Sean Daguewrote: > > 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. Tim > Would love to try to model everything under consideration here. It seems > like the conversations go around in circles a bit because everyone is > trying to keep everything in working memory, and paging out parts. > Diagrams hopefully ensure we all are talking about the same things. > > -Sean > > -- > Sean Dague > http://dague.net > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators