[openstack-dev] [nova][keystone] Pike PTG recap - quotas
lbragstad at gmail.com
Wed Mar 1 14:19:11 UTC 2017
FWIW - There was a lengthy discussion in #openstack-dev yesterday regarding
On Wed, Mar 1, 2017 at 5:42 AM, John Garbutt <john at johngarbutt.com> wrote:
> On 27 February 2017 at 21:18, Matt Riedemann <mriedemos at gmail.com> wrote:
> > We talked about a few things related to quotas at the PTG, some in
> > cross-project sessions earlier in the week and then some on Wednesday
> > morning in the Nova room. The full etherpad is here .
> > Counting quotas
> > ---------------
> > Melanie hit a problem with the counting quotas work in Ocata with
> respect to
> > how to handle quotas when the cell that an instance is running in is
> > The proposed solution is to track project/user ID information in the
> > "allocations" table in the Placement service so that we can get
> > information for quota usage from Placement rather than the cell. That
> > be a relatively simple change to move this forward and hopefully get the
> > counting quotas patches merged by p-1 so we have plenty of burn-in time
> > the new quotas code.
> > Centralizing limits in Keystone
> > -------------------------------
> > This actually came up mostly during the hierarchical quotas discussion on
> > Tuesday which was a cross-project session. The etherpad for that is here
> > . The idea here is that Keystone already knows about the project
> > hierarchy and can be a central location for resource limits so that the
> > various projects, like nova and cinder, don't have to have a similar data
> > model and API for limits, we can just make that common in Keystone. The
> > other projects would still track resource usage and calculate when a
> > is over the limit, but the hope is that the calculation and enforcement
> > be generalized so we don't have to implement the same thing in all of the
> > projects for calculating when something is over quota.
> > There is quite a bit of detail in the nova etherpad  about overbooking
> > and enforcement modes, which will need to be brought up as options in a
> > and then projects can sort out what makes the most sense (there might be
> > multiple enforcement models available).
> > We still have to figure out the data migration plan to get limits data
> > each project into Keystone, and what the API in Keystone is going to look
> > like, including what this looks like when you have multiple compute
> > endpoints in the service catalog, or regions, for example.
> > Sean Dague was going to start working on the spec for this.
> > Hierarchical quota support
> > --------------------------
> > The notes on hierarchical quota support are already in  and . We
> > agreed to not try and support hierarchical quotas in Nova until we were
> > using limits from Keystone so that we can avoid the complexity of both
> > systems (limits from Nova and limits from Keystone) in the same API
> code. We
> > also agreed to not block the counting quotas work that melwitt is doing
> > since that's already valuable on its own. It's also fair to say that
> > hierarchical quota support in Nova is a Queens item at the earliest
> given we
> > have to get limits stored in Keystone in Pike first.
> > Dealing with the os-qouta-class-sets API
> > ----------------------------------------
> > I had a spec  proposing to cleanup some issues with the
> > os-quota-class-sets API in Nova. We agreed that rather than spend time
> > fixing the latent issues in that API, we'd just invest that time in
> > and getting limits from Keystone, after which we'll revisit deprecating
> > quota classes API in Nova.
> >  https://etherpad.openstack.org/p/nova-ptg-pike-quotas
> >  https://etherpad.openstack.org/p/ptg-hierarchical-quotas
> >  https://review.openstack.org/#/c/411035/
> I started a quota backlog spec before the PTG to collect my thoughts here:
> I have updated that post summit to include updated details on
> hierarchy (ln134) when using keystone to store the limits. This mostly
> came from some side discussions in the API-WG room with morgan and
> It includes a small discussion on how the idea behind quota-class-sets
> could be turned into something usable, although that is now a problem
> for keystone's limits API.
> There were some side discussion around the move to placement meaning
> ironic quotas move from vCPU and RAM to custom resource classes. Its
> worth noting this largely supersedes the ideas we discussed here in
> flavor classes:
> I don't currently plan on taking that backlog spec further, as sdague
> is going to take moving this all forward.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev