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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
