On 12/18/2014 01:50 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 12:34 , Itamar Heim <[email protected]> wrote:
On 12/18/2014 01:24 PM, Michal Skrivanek wrote:
On Dec 18, 2014, at 11:54 , Itamar Heim <[email protected]> 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.
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
