[ovirt-devel] Feature review: Cluster parameters override

Itamar Heim iheim at redhat.com
Tue Dec 16 23:15:38 UTC 2014

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).

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

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

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

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

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

- what about export/import?

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

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


[1] https://bugzilla.redhat.com/show_bug.cgi?id=838487#c2
[2] https://bugzilla.redhat.com/show_bug.cgi?id=838490#c3

More information about the Devel mailing list