Hi,
In Mitaka nova introduced the "cpu_thread_policy" which can be specified in
flavor extra-specs. In the original spec, and in the original implementation,
not specifying the thread policy in the flavor was supposed to be equivalent to
specifying a policy of "prefer", and in both cases if the image set a policy
then nova would use the image policy.
In Newton, the code was changed to fix a bug but there was an unforeseen side
effect. Now the behaviour is different depending on whether the flavor
specifies no policy at all or specifies a policy of "prefer". Specifically, if
the flavor doesn't specify a policy at all and the image does then we'll use the
flavor policy. However, if the flavor specifies a policy of "prefer" and the
image specifies a different policy then we'll use the flavor policy.
This is clearly a bug (tracked as part of bug #1687077), but it's now been out
in the wild for two releases (Newton and Ocata).
What do operators think we should do? I see two options, neither of which is
really ideal:
1) Decide that the "new" behaviour has been out in the wild long enough to
become the defacto standard and update the docs to reflect this. This breaks
the "None and 'prefer' are equivalent" model that was originally intended.
2) Fix the bug to revert back to the original behaviour and backport the fix to
Ocata. Backporting to Newton might not happen since it's in phase II
maintenance. This could potentially break anyone that has come to rely on the
"new" behaviour.
Either change is trivial from a dev standpoint, so it's really an operator
issue--what makes the most sense for operators/users?
Chris
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
