Public bug reported: When we resize a server, we update the RequestSpec.flavor because for later move operations of the server, the RequestSpec is what gets passed to the scheduler, so naturally we need the RequestSpec.flavor to match the instance.flavor after the instance is resized. That happens here:
https://github.com/openstack/nova/blob/4c37ff72e5446c835a48d569dd5a1416fcd36c71/nova/conductor/manager.py#L313 https://github.com/openstack/nova/blob/4c37ff72e5446c835a48d569dd5a1416fcd36c71/nova/conductor/manager.py#L352 However, if the resize is reverted, we don't actually rollback the RequestSpec.flavor to the previously flavor (instance.old_flavor): https://github.com/openstack/nova/blob/4c37ff72e5446c835a48d569dd5a1416fcd36c71/nova/compute/api.py#L3322 So consider this scenario: 1. create server with flavor 1 2. resize to server 2 (VERIFY_RESIZE status); at this point the RequestSpec.flavor is 2 3. revert the resize 4. live migrate, shelve/unshelve, evacuate or cold migrate the server - the request spec passed to the scheduler will have flavor 2 rather than flavor 1 which could cause misleading scheduling failures, e.g. if flavor 2 is bigger than flavor 1 and there is no capacity for flavor 2 on any hosts, the scheduler would raise NoValidHost. ** Affects: nova Importance: Medium Status: Triaged ** Affects: nova/ocata Importance: Undecided Status: New ** Affects: nova/pike Importance: Undecided Status: New ** Affects: nova/queens Importance: Undecided Status: New ** Tags: request-spec resize -- 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/1785339 Title: RequestSpec.flavor is not reverted on resize revert Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) ocata series: New Status in OpenStack Compute (nova) pike series: New Status in OpenStack Compute (nova) queens series: New Bug description: When we resize a server, we update the RequestSpec.flavor because for later move operations of the server, the RequestSpec is what gets passed to the scheduler, so naturally we need the RequestSpec.flavor to match the instance.flavor after the instance is resized. That happens here: https://github.com/openstack/nova/blob/4c37ff72e5446c835a48d569dd5a1416fcd36c71/nova/conductor/manager.py#L313 https://github.com/openstack/nova/blob/4c37ff72e5446c835a48d569dd5a1416fcd36c71/nova/conductor/manager.py#L352 However, if the resize is reverted, we don't actually rollback the RequestSpec.flavor to the previously flavor (instance.old_flavor): https://github.com/openstack/nova/blob/4c37ff72e5446c835a48d569dd5a1416fcd36c71/nova/compute/api.py#L3322 So consider this scenario: 1. create server with flavor 1 2. resize to server 2 (VERIFY_RESIZE status); at this point the RequestSpec.flavor is 2 3. revert the resize 4. live migrate, shelve/unshelve, evacuate or cold migrate the server - the request spec passed to the scheduler will have flavor 2 rather than flavor 1 which could cause misleading scheduling failures, e.g. if flavor 2 is bigger than flavor 1 and there is no capacity for flavor 2 on any hosts, the scheduler would raise NoValidHost. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1785339/+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
