Re: [ovirt-devel] Feature review: Cluster parameters override

On 12/12/2014 04:42 PM, Sandro Bonazzola wrote: 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. Thanks, Itamar [1] https://bugzilla.redhat.com/show_bug.cgi?id=838487#c2 [2] https://bugzilla.redhat.com/show_bug.cgi?id=838490#c3