Feature review: Cluster parameters override
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, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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
On Dec 17, 2014, at 00:15 , Itamar Heim <iheim@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
On 12/18/2014 12:52 PM, Michal Skrivanek wrote:
looking at the bugs, seems i had an opinion on this 2 years ago[1]
- 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.) 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? also, why expose an internal arbitrary string to the user, which they have no way to understand/know what it means?
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim@redhat.com> wrote:
On 12/18/2014 12:52 PM, Michal Skrivanek wrote:
looking at the bugs, seems i had an opinion on this 2 years ago[1]
- 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.) 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.
On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim@redhat.com> wrote:
On 12/18/2014 12:52 PM, Michal Skrivanek wrote:
looking at the bugs, seems i had an opinion on this 2 years ago[1]
- 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.) 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. 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)
On Dec 18, 2014, at 12:34 , Itamar Heim <iheim@redhat.com> wrote:
On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim@redhat.com> wrote:
On 12/18/2014 12:52 PM, Michal Skrivanek wrote:
looking at the bugs, seems i had an opinion on this 2 years ago[1]
- 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.) 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)
On 12/18/2014 01:50 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 12:34 , Itamar Heim <iheim@redhat.com> wrote:
On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim@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.
On 18/12/14 12:34, Itamar Heim wrote:
we never tested 3.5 on rhel7 machine type. Sorry, what?
http://www.ovirt.org/OVirt_3.5.1_Release_Notes#Red_Hat_Enterprise_Linux_7_an... How can you support it in the next release when it was never tested? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On 12/18/2014 02:00 PM, Sven Kieske wrote:
On 18/12/14 12:34, Itamar Heim wrote:
we never tested 3.5 on rhel7 machine type. Sorry, what?
http://www.ovirt.org/OVirt_3.5.1_Release_Notes#Red_Hat_Enterprise_Linux_7_an...
How can you support it in the next release when it was never tested?
3.5 cluster uses -m rhel6.5 for either rhel 6 or rhel 7 host. this is about using a -m rhel7.0 mode
Il 18/12/2014 13:16, Itamar Heim ha scritto:
On 12/18/2014 02:00 PM, Sven Kieske wrote:
On 18/12/14 12:34, Itamar Heim wrote:
we never tested 3.5 on rhel7 machine type. Sorry, what?
http://www.ovirt.org/OVirt_3.5.1_Release_Notes#Red_Hat_Enterprise_Linux_7_an...
How can you support it in the next release when it was never tested?
It's tested and up and running at least on one of our installs. CCing didi.
3.5 cluster uses -m rhel6.5 for either rhel 6 or rhel 7 host. this is about using a -m rhel7.0 mode _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 18 Dec 2014, at 13:41, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Il 18/12/2014 13:16, Itamar Heim ha scritto:
On 12/18/2014 02:00 PM, Sven Kieske wrote:
On 18/12/14 12:34, Itamar Heim wrote: we never tested 3.5 on rhel7 machine type. Sorry, what?
http://www.ovirt.org/OVirt_3.5.1_Release_Notes#Red_Hat_Enterprise_Linux_7_an...
How can you support it in the next release when it was never tested?
Machine type != OS This is what hardware is emulated inside the VM. We're keeping the same 6.5-ish hw in 3.5 on all supported platforms
It's tested and up and running at least on one of our installs. CCing didi.
3.5 cluster uses -m rhel6.5 for either rhel 6 or rhel 7 host. this is about using a -m rhel7.0 mode _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 18/12/14 13:16, Itamar Heim wrote:
3.5 cluster uses -m rhel6.5 for either rhel 6 or rhel 7 host. this is about using a -m rhel7.0 mode
Thanks for the clarification. What would be the difference inside the vm? Different emulated hardware? Other setting? Where can I look up the machine levels and their specific meaning (any link to a doc)? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
On 12/18/2014 06:35 PM, Sven Kieske wrote:
On 18/12/14 13:16, Itamar Heim wrote:
3.5 cluster uses -m rhel6.5 for either rhel 6 or rhel 7 host. this is about using a -m rhel7.0 mode
Thanks for the clarification.
What would be the difference inside the vm? Different emulated hardware? Other setting?
Where can I look up the machine levels and their specific meaning (any link to a doc)?
I don't know there is a doc covering this other than the code. it usually covers various tweaks like "oh, this flag should be enabled for this cpu type", which can't be done without breaking compatibility in a cluster so its fixed only for the next emulation level (i.e., -cpu westmere could have more flags with -m rhel66 compared to -m rhel65). I don't think this is documented too much anywhere, its just a method to maintain compatibility (and yes, virtual hardware changes more or less as well with that change, again, can't remember a concrete instance)
participants (5)
-
Itamar Heim -
Michal Skrivanek -
Michal Skrivanek -
Sandro Bonazzola -
Sven Kieske