8:42 a.m.
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
5:15 p.m.
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
4:52 a.m.
On Dec 17, 2014, at 00:15 , Itamar Heim <iheim(a)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
4:54 a.m.
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?
also, why expose an internal arbitrary string to the user, which they
have no way to understand/know what it means?
5:24 a.m.
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim(a)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.
5:34 a.m.
On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 11:54 , Itamar Heim <iheim(a)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.
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)
5:50 a.m.
On Dec 18, 2014, at 12:34 , Itamar Heim <iheim(a)redhat.com> wrote:
On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
>
> On Dec 18, 2014, at 11:54 , Itamar Heim <iheim(a)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)
6:15 a.m.
On 12/18/2014 01:50 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 12:34 , Itamar Heim <iheim(a)redhat.com> wrote:
> On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
>>
>> On Dec 18, 2014, at 11:54 , Itamar Heim <iheim(a)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.
6 a.m.
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...
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
6:16 a.m.
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...
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
6:40 a.m.
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...
>
> 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(a)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
9:35 a.m.
On 18 Dec 2014, at 13:41, Sandro Bonazzola
<sbonazzo(a)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...
>>
>> 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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
10:35 a.m.
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
3:32 p.m.
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)
3657
days inactive
3663
days old
13 comments
5 participants
participants (5)
-
Itamar Heim -
Michal Skrivanek -
Michal Skrivanek -
Sandro Bonazzola -
Sven Kieske