yahoo-eng-team team mailing list archive

[OpenStack Infra <1659266@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/428352
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c2e1133be15254747c207cce7805bf56f3cca6fa
Submitter: Jenkins
Branch:    master

commit c2e1133be15254747c207cce7805bf56f3cca6fa
Author: John Garbutt <john.garbutt@xxxxxxxxxxxxx>
Date:   Thu Feb 2 18:41:46 2017 +0000

    Stop swap allocations being wrong due to MB vs GB
    
    Swap is in MB, but allocations for disk are in GB.
    
    We totally should claim disk in GB, for now lets just round up the swap
    allocation to the next GB. While this is wasteful, its the only safe
    answer to ensure you don't over commit resources on the node.
    
    Updated the test so the swap is 1023MB, after rounding up this should
    claim the same 1GB extra space for swap.
    
    Closes-Bug: #1659266
    
    Change-Id: If50eab870b2c50f4055668143780574e1350a438


** Changed in: nova
       Status: In Progress => Fix Released

-- 
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/1659266

Title:
  Disk allocation for instance is not good with swap

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When creating the allocation for the instance, we lookup the flavor to
  know the disk sizes for root, ephemeral and gb and we basically sum
  them.

  https://github.com/openstack/nova/blob/7d04c78c1e2c26125eff5b1a8543b1ac5d027107/nova/scheduler/client/report.py#L129-L131

  Unfortunately, since both root and ephemeral size are expressed in GB
  while swap is expressed in MB, the sum is not good.

  See how the DiskFilter works for accounting resources :
  https://github.com/openstack/nova/blob/3cafa7f5bd0775b8ba49080226c03f8a91468d7d/nova/scheduler/filters/disk_filter.py#L36-L38

  We should change the logic to ceil to the next GB if modulo(root +
  ephemeral * 1024 + swap / 1024) is not rounded to 0 since we want to
  count allocations as the Inventory only counts by GB.

  That's suboptimal and a long-term solution would be to report
  inventories in bytes (as the smallest attribute) but that's a big
  change so probably requiring a BP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1659266/+subscriptions