On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim(a)redhat.com> wrote:
> On 12/18/2014 12:52 PM, Michal Skrivanek wrote:
>>> - not clear if the "emulation levels" to user are based on compat
levels (3.3, 3.4, 3.5, 3.6, etc.), or the actual string (-m rhel6.5, -m rhel7.1,e tc.)
>>>> looking at the bugs, seems i had an opinion on this 2 years ago[1]
>> the actual string of machine type. The changes for compat level are more complex
than machine type. Also, only the machine type "guarantees" the hw stays the
same.
>> we can look at the compat level further, but so far the machine type is the only
thing defining the supported features. From the scheduler perspective it seems to me
it's better to create two clusters. Cluster is supposed to define the supported
features.
>> Is anything not covered?
>>
>
> how do you know which of the more advanced features in your current cluster level
were not tested with the lower emulation level?
well, you don't, and it's likely it wasn't. It never is tested on any other
than the latest machine type (with exception of 3.6 on rhel 7 and 6.6)….we can warn on
"anything else than the latest from 6.x and 7.x" .
> also, why expose an internal arbitrary string to the user, which they have no way to
understand/know what it means?
assuming cluster as the definition of same features - because it is the only thing which
have some meaning.
For 3.5 cluster level you can define the hw. it's tested on 6.6 and 7.0 machine
types. When you want to override later you can use any of these two without a warning; and
everything else will warn. You can go lower (and potentially miss the features), you can
go higher (say, 6.7 and 7.1 machine types) - then we should warn.
we never tested 3.5 on rhel7 machine type.
we shouldn't let user create a situation we never tested for, hence we
should limit to the cluster levels, with their implied emulation levels
and set of supported features for that cluster level (derived from vm
compatibility level)