Open Stack

Sorry for the late reply, but see below.

On Mon, 2017-05-15 at 11:46 -0600, Chris Friesen wrote:
> 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.

Whatever will or has been chosen should match the documentation.
Personally, we would never do anything other than specifying the policy
in the flavor as our flavors are associated w/ HW  profiles but I could
see how other operators might manage things differently. That being
said, that sort of thing should not necessarily be user controlled and
I haven't really explored Glance property protections.. 

So from my point of view "cpu_thread_policy" set in the flavor should
take precedence over anything else.

-m

> 
> 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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operato
> rs