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

Chris Friesen chris.friesen at windriver.com
Thu May 25 21:22:13 UTC 2017


On 05/25/2017 01:53 PM, Marc Heckmann wrote:
> On Mon, 2017-05-15 at 11:46 -0600, Chris Friesen wrote:

>> 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.

So a vote to keep the status quo and change the documentation to match?  (Since 
the current behaviour doesn't match the original documentation.)

Incidentally, it's allowed to be specified in an image because whether or not HT 
is desirable depends entirely on the application code.  It may be faster with 
"isolate", or it may be faster with "require" and double the vCPUs in the guest. 
  If the software in the guest is licensed per vCPU then "isolate" might make 
sense to maximize performance per licensing dollar.

"prefer" is almost never a sensible choice for anything that cares about 
performance--it was always intended to be a way to represent "the behaviour that 
you get if you don't specify a cpu thread policy".

Oh, and I'd assume that a customer would be billed for the number of host cores 
actually used...so "isolate" with N vCPUs and "require" with 2*N vCPUs would end 
up costing the same.

Chris






More information about the OpenStack-operators mailing list