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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operato > rs _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
