Open Stack

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 [1].

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 down. The proposed solution is to track project/user ID 
information in the "allocations" table in the Placement service so that 
we can get allocation information for quota usage from Placement rather 
than the cell. That should 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 for 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 [2]. 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 
request is over the limit, but the hope is that the calculation and 
enforcement can 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 [1] about 
overbooking and enforcement modes, which will need to be brought up as 
options in a spec 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 
from 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 [1] and [2]. 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 [3] 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 
storing and getting limits from Keystone, after which we'll revisit 
deprecating the quota classes API in Nova.

[1] https://etherpad.openstack.org/p/nova-ptg-pike-quotas
[2] https://etherpad.openstack.org/p/ptg-hierarchical-quotas
[3] https://review.openstack.org/#/c/411035/

-- 

Thanks,

Matt Riedemann