DescriptionBrendan Shephard
2019-05-24 01:56:28 UTC
Description of problem:
When creating instances with:
openstack server create --flavor 87af2006-2186-4693-88f6-32df9a5662b6 --nic net-id=6ebf2d5b-c496-4e64-894a-0b06bf2ce3c9 --image b7be7e6d-6501-40e0-8815-578187b4cf0a --min=2 --max=2 ian -vv
Scheduling of the instance fails the NUMATopologyFilter as the it tries to pin both instances to the same CPU's.
However, scheduling them one at a time in succession works fine.
Version-Release number of selected component (if applicable):
python-nova-14.1.0-27.el7ost.noarch
How reproducible:
All the time in this environment
Steps to Reproduce:
1. Configure flavor for NUMA related settings (Output attached)
2. Create AZ for the NUMA Compute Nodes
3. Provision using openstack server create --flavor NUMA_FLAVOR [...] --min=2 --max=2
Actual results:
Both instances fail to build.
Both instances try to pin the same CPU's
Expected results:
CPU's would be scheduled on separate nodes, or at very least different CPU cores.
Additional info:
Debug scheduler and conductor logs attached
this is a known issue that was caused by a downstream only fix for live migration with cpu pinning.
it was fixed in in the january z stream of osp 10
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/release_notes/ch03s05
as a resolution of bug https://bugzilla.redhat.com/show_bug.cgi?id=1613242
the report states that version python-nova-14.1.0-27.el7ost.noarch
but this was fixed in openstack-nova-14.1.0-35.el7ost
since this is fixed in a later z stream im closing this as duplicate of the original bug and i advise the customer to
upgrade the latest osp 10 z stream and set the cpu_pinning_migration_quick_fail option to false in the workarouds section
of the nova.conf.
note while as a https://bugzilla.redhat.com/show_bug.cgi?id=1613242 does not mention that if fixes multi create it does.
*** This bug has been marked as a duplicate of bug 1613242 ***