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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
