stephen retroactivly modified the spec in 2016 and added the instance metadata item because it
added to the code but it was never inteneded to support enabling pinning via the flavor
enabling/disabling cpu pinning was intended to be admin only via the flavor which is why
handeling of conficting values was not called out in the spec for hw:cpu_policy but was for hw:cpu_thread_policy and hw_cpu_tread_policy.
we initally had a convention until mitaka or newton to give precedece to the flavor and whenever
there was a confict, use the flavor value and ignore the image. we have since changed our stance on that and moved newer code to rasie an explcit error.
the real bug is that hw_cpu_policy was supported in the flavor at all in the code but its too late to remove that now.
for what its worth the thread policies spec clearly stated that the image metadata value would only be honnored if the flavor value was not set /specs. openstack. org/openstack/ nova-specs/ specs/liberty/ approved/ virt-driver- cpu-pinning. html#proposed- change
https:/
if both were set i would have expect the vm to boot with the flavor value. /specs. openstack. org/openstack/ nova-specs/ specs/juno/ approved/ virt-driver- cpu-pinning. html#proposed- change /github. com/openstack/ nova-specs/ blob/cd327a0a5f 4b399b6ec713252 c6ebee1909f621b /specs/ kilo/implemente d/virt- driver- cpu-pinning. rst
if you look at the juno cpu pinning spec the image property for cpu pinnign was never actully approved in juno where we clarified that the image metadata vlaue would be honered only if the flavor value was unset.
https:/
when it was reporposed for kilo image metadata support was also not part of the spec.
https:/
stephen retroactivly modified the spec in 2016 and added the instance metadata item because it
added to the code but it was never inteneded to support enabling pinning via the flavor
https:/ /github. com/openstack/ nova-specs/ commit/ 15e23b2e83aca19 7a3bef8f354e941 7bc37707e3# diff-b0487c82c3 3edaae2d3ed88c9 9bd0e5aR59
enabling/disabling cpu pinning was intended to be admin only via the flavor which is why thread_ policy and hw_cpu_ tread_policy.
handeling of conficting values was not called out in the spec for hw:cpu_policy but was for hw:cpu_
we initally had a convention until mitaka or newton to give precedece to the flavor and whenever
there was a confict, use the flavor value and ignore the image. we have since changed our stance on that and moved newer code to rasie an explcit error.
the real bug is that hw_cpu_policy was supported in the flavor at all in the code but its too late to remove that now.