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.
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)
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
