[ovirt-devel] Feature review: Cluster parameters override

[Michal Skrivanek]

On Dec 17, 2014, at 00:15 , Itamar Heim <iheim at redhat.com> wrote:

> On 12/12/2014 04:42 PM, Sandro Bonazzola wrote:
>> Hi,
>> Cluster parameters override[1] has been targeted to 3.6.0.
>> Can you please provide
>> - A contingency plan in case the feature won't be ready
>> - A brief text which will be used in release notes
>> - A section with links to test cases or a description of the testing required for validating the feature?
>> 
>> [1] http://www.ovirt.org/Features/Cluster_parameters_override
>> 
>> Thanks,
>> 
> 
> follow up questions / nuances in flow to Eldan:
> - with 3.6 cluster level having -m rhel7.x, changing the cluster level to 3.6 should prompt a dialog to admin about this change, and ask if to change all vm's which have cluster default emulation mode, or not (which should change their emulation mode to 3.5 from cluster's default).

There's no warning now. Can be added.

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

> 
> - need to have logic to validate unsupported cluster levels/emulation levels. i.e., 3.6/rhel7 will only support -m rhel65 and above, so you can't set a vm to -m rhel6.4 and then upgrade cluster to 3.6.
> also note a 3.6 cluster can't have 3.4 compat in it, only 3.5. as .el7 was only officially supported in 3.5.

matching the compat level against the selected machine type can be added

> 
> - need to warn user in gui if value of cpu or emulation is higher than cluster than scheduling will not be optimal.

a popup or red text in the dialog based on the previous comment

> 
> - if adding logic to scheduler, need to check if changes to optaplanner schedulers is needed (or it gets them for free), as the more complex scheduling this may cause may make optaplanner "much more needed" to re-optimize the cluster.

scheduler is aware of the machine type now and filters out hosts not supporting it. There should be no impact/change in optaplanner 

> 
> - you mention this is for both vm's and templates. what about instance types (maybe)? what about pools?

covered. it doesn't break the instance type association when changed (unlike RAM,CPU)
> 
> - what about export/import?

covered

> 
> - are those field editable via user api, or admin level only?

both

> 
> - please note in [1] i also mention the need to change all feature validations to be based on vm compatibility level, rather than cluster compat level - worth reviewing what is affected by cluster level and see if can affect this.
> 
> - please note [2] - no need to affect scheduler if compat or cpu are lower than cluster level.
> 
> Thanks,
>   Itamar
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=838487#c2
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=838490#c3