[Openstack-operators] preferred option to fix long-standing user-visible bug in nova?

Chris Friesen chris.friesen at windriver.com
Mon May 15 17:46:48 UTC 2017


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



More information about the OpenStack-operators mailing list