[ovirt-devel] Feature review: Cluster parameters override

[Itamar Heim]

On 12/18/2014 01:50 PM, Michal Skrivanek wrote:
>
> On Dec 18, 2014, at 12:34 , Itamar Heim <iheim at redhat.com> wrote:
>
>> 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.
>
> sorry, right, only 6.6
>
>> 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)
>
>
> if warning is enough then let's do that. Or you think we should enforce blocking…we always end up relaxing hard constraints afterwards..so IMHO warning is enough
> currently, the only tested machine type is the one from the list per cluster level.
>
> for the upgrade flow…I may have misunderstood. So my thinking is:
> - 3.5 cluster level with 6.6 machine type
> - upgrade just the machine type to 7.x . This will include the warning that it wasn't tested
> - once everything ok you can change the cluster level to 3.6. (an option to change all the VMs to cluster's default might be helpful…just so I don't have to go one by one and remove the override)
>

my thinking is the VM has a "cluster compatibility level" field.
its the "reverse" from dc/cluster.
you can't upgrade the vm compat level until the cluster was upgraded.
you also can't upgrade the cluster compat level if there are VMs with 
unsupported modes (a 4.0 cluster will not support say a vm with 3.5 
compat level).

flow is:
- all VMs start with "VM Compat level: Cluster Default"
- you upgrade the cluster to 3.6, and either choose all VMs to be 
upgraded (no change) or to "keep current compat level", in which case 
all VMs.CompatLevel will be changed to 3.5.