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