[ovirt-devel] Feature review: Cluster parameters override

[Itamar Heim]

On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
>
> On Dec 18, 2014, at 11:54 , Itamar Heim <iheim at 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)