Open Stack

On Tue, 8 Nov 2016 14:25:08 -0600, Matt Riedemann wrote:
> While talking about that in the session, there was some brainstorming on
> doing limit checks differently in the API. Basically, do away with
> reservations, do a quick DB query to check quota before an operation
> begins, and if it's OK go forward. There will be races as tenants reach
> the end of quota limits, but maybe this is OK. The upside is we
> shouldn't get out of sync (which has been a problem for operators to
> deal with), but there is a potential to race for the last usages which
> might lead to overconsumption of resources.

Yes, with the counting approach we could have a tenant consume more 
resources than they have quota if racing near the end of quota limits 
(until claims are moved to the API). I think the commit quota 
immediately approach would also prevent getting out of sync but it has 
the downside that some quota reads/writes still have to be initiated by 
the compute host (resize and nova-net fixed_ips). The upside to the 
counting approach is that it eliminates the need to write quota usage 
for a failed resize. The nova-net fixed_ips are still an issue with the 
counting approach too but nova-net is deprecated and we could remove the 
quota read/writes from the compute host for them "soon." The counting 
approach is better than committing quota immediately in that it 
simplifies things a lot and is the only solution that has the potential 
to remove quota reads/writes from the compute host completely.

> There are some open questions around the 'fast and loose' approach like
> are there things we need to count which aren't in the API database, and
> can we do this efficiently for things that nova doesn't track in it's
> database, like floating/fixed IPs in neutron?

I think the only resources that are unclear as to whether they are in 
the API database are things like cores, ram, etc and I thought these 
will end up being represented in the inventories or allocations table 
once the resource providers work progresses further. And I didn't think 
we need to account for floating/fixed IPs in neutron because we don't 
currently track them anyway -- neutron checks quota itself and returns 
403 if quota is exceeded.

-melanie