----- Original Message -----
From: "Shireesh Anjal" <sanjal(a)redhat.com>
To: "Mike Kolesnik" <mkolesni(a)redhat.com>
Sent: Monday, March 18, 2013 9:41:33 AM
Subject: Re: [Engine-devel] FeatureSupported and compatibility versions
On 03/18/2013 12:59 PM, Mike Kolesnik wrote:
> ----- Original Message -----
>> Hi all,
>> The current mechanism in oVirt to check whether a feature is
>> in a particular compatibility version is to use the
>> class. e.g.
>> Checks whether the "network linking" feature is supported for the
>> VM's cluster compatibility version. This internally checks whether
>> value of the corresponding config (NetworkLinkingSupported) for
>> given compatibility version is true/false.
>> I'm not sure if this is a good idea, since a feature is typically
>> supported "from" a particular version. E.g. Gluster support was
>> introduced in 3.1, and it continues to be available in all
>> versions. So I see no point in adding configuration for every
>> indicating whether the feature is supported in that version or
>> not. I
>> suggest to use either of the following options:
> You can "merge" the configs into a single config when older
> versions go out of the supported versions for the system.
> i.e. in 4.0 you can have upgrade script that merges all
> GlusterFeatureSupported to one entry instead of several.
>> 1) Instead of using a boolean config for each version, use a
>> string config that indicates the "supported from" version e.g.
>> GlusterSupportedFrom = 3.1. There could be rare cases where a
>> for some reason, is removed in some release. In such cases, we
>> one additional config for the "supported to" version.
>> 2) Continue with the boolean approach, but do not have entries for
>> version; rather make use of the "default value" for majority of
>> and add the explicit version mapping for the minority e.g.
>> GlusterSupported = true by default, and false in case of 3.0 (only
>> config required for 3.0)
> I'm not sure why we would want to complicate this simple mechanism?
> Is there much to gain?
I think option 1 suggested above is simpler - to implement as well as
Let me give you an example of why I don't like current mechanism. I
introduce a version check for a feature that was introduced in 3.1.
being asked now to add three entries in config
3.0 - false
3.1 - true
3.2 - true
It will also mean that when 3.3 goes out, someone has to make sure
another entry is added for 3.3-true. I think it is not logical as
as scalable if you have more versions. And it sounds far more complex
(to maintain) than just having
I think we should look at it from two directions -
a. the Java API we provide - Config and Feature classes
b. The database.
I personally also had thoughts that the current mechanism is lacking, in sense of defining
"ranges of versions" for features.
We should have a concept of "starts with version" and "supported until
I think the logic for that should be implemented at db and at the Config class.
I think the API provided by featureSupported should be kept.
<Feature>SupportedFrom = 3.1
So I would like to know if there are any objections to my proposal. I
intend to use this for at least the gluster related features.
>> Engine-devel mailing list
Engine-devel mailing list