Description of problem: Booting an instance with 'hw:cpu_thread_policy=isolate' should not be possible on a host with hyperthreads. However, as first seen in bug 1850400, this is clearly not the case. It appears that the fallback query we use to allow us to schedule to both hosts with new style PCPU configuration ('[compute] cpu_dedicated_set', '[compute] cpu_shared_set') and old style configuration ('[DEFAULT] vcpu_pin_set') is the culprit. Specifically, there are two requests against placement: one for $flavor.vcpu PCPU inventory and HW_CPU_HYPERTHREADING=forbidden (due to the isolate trait), and another for $flavor.vcpu VCPU inventory. The first request fails but the host can be picked up by the second request if it happens to have enough VCPU inventory. We should be late checking on the host to avoid this situation. Version-Release number of selected component (if applicable): OSP 16.1.0. How reproducible: Always. Steps to Reproduce: 1. Using a host with hyperthreading support enabled, configure both '[compute] cpu_dedicated_set' and '[compute] cpu_shared_set' 2. Boot an instance with the 'hw:cpu_thread_policy=isolate' extra spec. Actual results: Instance boots on host and consumes 'VCPU' inventory. Expected results: Instance should not boot on host, since 'isolate' policy should reject hosts with hyperthreading. Additional info:
the steps to reproduce are missing the fact that the fallback pcpu placment query need to be enabled(this is the default) for this to happen. but yes this is otherwise correct.
*** Bug 1867986 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1 bug fix and enhancement advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:4284