yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

Logs for the failed debian rocky run:

http://logs.openstack.org/75/597175/1/check/puppet-openstack-
integration-4-scenario001-tempest-debian-stable-luminous/fd38fcf/logs/

This was also reported by the xenserver CI:

http://lists.openstack.org/pipermail/openstack-
dev/2018-August/133896.html

My guess is the local ProviderTree cache of inventory thinks nothing has
changed when we set allocation_ratio on the provider inventory so it
never actually updates the inventory remotely and we're left with
initial values of 0.0.

** Changed in: nova
       Status: New => Confirmed

** Changed in: nova
   Importance: Undecided => High

** Also affects: nova/rocky
   Importance: Undecided
       Status: New

** Changed in: nova/rocky
       Status: New => Confirmed

** Changed in: nova/rocky
   Importance: Undecided => High

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

Title:
  placement allocation_ratio initialized with 0.0

Status in OpenStack Compute (nova):
  Confirmed
Status in OpenStack Compute (nova) rocky series:
  Confirmed

Bug description:
  After I just finished packaging Rocky, I wanted to test it with
  puppet-openstack. Then I couldn't boot VMs after the puppet run,
  because allocation_ration in placement is set to 0.0 by default:

  # openstack resource provider list
  +--------------------------------------+-------------------+------------+
  | uuid                                 | name              | generation |
  +--------------------------------------+-------------------+------------+
  | f9716941-356f-4a2e-b5ea-31c3c1630892 | poi.infomaniak.ch |          2 |
  +--------------------------------------+-------------------+------------+
  # openstack resource provider show f9716941-356f-4a2e-b5ea-31c3c1630892
  +------------+--------------------------------------+
  | Field      | Value                                |
  +------------+--------------------------------------+
  | uuid       | f9716941-356f-4a2e-b5ea-31c3c1630892 |
  | name       | poi.infomaniak.ch                    |
  | generation | 2                                    |
  +------------+--------------------------------------+
  # openstack resource provider inventory list f9716941-356f-4a2e-b5ea-31c3c1630892
  +----------------+----------+-----------+------------------+-------+----------+----------+
  | resource_class | reserved | step_size | allocation_ratio | total | min_unit | max_unit |
  +----------------+----------+-----------+------------------+-------+----------+----------+
  | VCPU           |        0 |         1 |              0.0 |     4 |        1 |        4 |
  | DISK_GB        |        0 |         1 |              0.0 |    19 |        1 |       19 |
  | MEMORY_MB      |      512 |         1 |              0.0 |  7987 |        1 |     7987 |
  +----------------+----------+-----------+------------------+-------+----------+----------+

  Later on, setting-up correct allocation_ratio fixed the problem:
  # openstack resource provider inventory class set --allocation_ratio 16.0 --total 4 f9716941-356f-4a2e-b5ea-31c3c1630892 VCPU
  +------------------+------------+
  | Field            | Value      |
  +------------------+------------+
  | max_unit         | 2147483647 |
  | min_unit         | 1          |
  | step_size        | 1          |
  | reserved         | 0          |
  | allocation_ratio | 16.0       |
  | total            | 4          |
  +------------------+------------+
  # openstack resource provider inventory list f9716941-356f-4a2e-b5ea-31c3c1630892
  +----------------+------------------+----------+------------+-----------+----------+-------+
  | resource_class | allocation_ratio | reserved |   max_unit | step_size | min_unit | total |
  +----------------+------------------+----------+------------+-----------+----------+-------+
  | DISK_GB        |              0.0 |        0 |         19 |         1 |        1 |    19 |
  | MEMORY_MB      |              0.0 |      512 |       7987 |         1 |        1 |  7987 |
  | VCPU           |             16.0 |        0 | 2147483647 |         1 |        1 |     4 |
  +----------------+------------------+----------+------------+-----------+----------+-------+

  so, after this, I could boot VMs normally. Though clearly,
  allocation_ratio should not be zero by default.

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