[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.
Thanks,
Itamar
[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