9f57d16f38
If the image change during a rebuild it's possible for the request NUMA topology to change. As a rebuild uses a noop claim in the resource tracker the NUMA topology will not be updated as part of a rebuild. If the NUMA constraints do not change, a rebuild will continue as normal. If the new constraints conflict with the existing NUMA constraints of the instance the rebuild will be rejected without altering the status of the instance. This change introduces an API check to block rebuild when the NUMA requirements for the new image do not match the existing NUMA constraints. This is in line with the previous check introduced to prevent the rebuild of volume-backed instances which similarly are not supported. This change adds functional tests to assert the expected behaviour of rebuilding NUMA instances with new images. This change also asserts that in place rebuilds of numa instances is currently not supported. Conflicts: nova/api/openstack/compute/servers.py nova/tests/functional/libvirt/test_numa_servers.py NOTE(sean-k-mooney): due to the lack of Ifcda7336d56c9b623720ee018ec5697740986273 the Fake HostInfo objects created in the functional tests were updated to use the NUMAHostInfo class. Prior to Ifcda7336d56c9b623720ee018ec5697740986273 the Fake HostInfo class did not construct a numa topology from the kwargs and instead only set a numa topology if it was passed in during construction. In older release the initialization of the numa topology from kwargs was a feature of NUMAHostInfo. The servers.py conflicts are due to a lack of I5576fa2a67d2771614266022428b4a95487ab6d5 in Stein. Closes-Bug: #1763766 Partial-implements: blueprint inplace-rebuild-of-numa-instances Change-Id: I0322d872bdff68936033a6f5a54e8296a6fb3434 (cherry picked from commit |
||
---|---|---|
.. | ||
__init__.py | ||
base.py | ||
test_numa_servers.py | ||
test_pci_sriov_servers.py | ||
test_report_cpu_traits.py | ||
test_reshape.py | ||
test_rt_servers.py | ||
test_shared_resource_provider.py |