yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #26233
[Bug 1369696] Re: quota_reserve headroom might be wrong if project_quotas != user_quotas
** Changed in: nova
Status: Fix Committed => Fix Released
** Changed in: nova
Milestone: None => kilo-1
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1369696
Title:
quota_reserve headroom might be wrong if project_quotas != user_quotas
Status in OpenStack Compute (Nova):
Fix Released
Bug description:
Looking at this code:
https://github.com/openstack/nova/blob/2014.2.b3/nova/db/sqlalchemy/api.py#L3343
Notice the headroom variable is created based on usages and
user_quotas:
headroom = dict((res, user_quotas[res] -
(usages[res]['in_use'] + usages[res]['reserved']))
for res in user_quotas.keys())
but the usages variable is based on whether or not project_quotas ==
user_quotas:
if project_quotas == user_quotas:
usages = project_usages
else:
usages = user_usages
So it appears that headroom could be incorrect if project_quotas !=
user_quotas.
Looking at what uses headroom, the compute API uses this in the
instance create and resize flows. For resize it's just using headroom
to plug into an error message for the TooManyInstances exception.
In the create flow (_check_num_instances_quota) it's used for a bit
more advanced logic with recursion.
We should probably just remove the headroom calculation from
quota_reserve and let the caller figure it out and what needs to be
done with it. It's also odd that this is happening in the DB API
because it's dealing with instance quotas but maybe I'm not doing
anything with instance quotas, maybe I'm doing things with security
group or fixed IP quotas - so this code seems to be in the wrong
place. Maybe it's just conveniently placed here given the other data
already in scope from the database.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1369696/+subscriptions
References