← Back to team overview

yahoo-eng-team team mailing list archive

[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