[openstack-dev] [nova] cells v2 ocata summit sessions recap
melanie witt
melwittt at gmail.com
Wed Nov 9 01:47:43 UTC 2016
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
More information about the OpenStack-dev
mailing list