[Engine-devel] FeatureSupported and compatibility versions

[Shireesh Anjal]

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
>> supported
>> in a particular compatibility version is to use the FeatureSupported
>> class. e.g.
>>
>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion())
>>
>> Checks whether the "network linking" feature is supported for the the
>> VM's cluster compatibility version. This internally checks whether
>> the
>> value of the corresponding config (NetworkLinkingSupported) for the
>> 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 subsequent
>> versions. So I see no point in adding configuration for every version
>> 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 single
>> string config that indicates the "supported from" version e.g.
>> GlusterSupportedFrom = 3.1. There could be rare  cases where a
>> feature,
>> for some reason, is removed in some release. In such cases, we could
>> use
>> one additional config for the "supported to" version.
>>
>> 2) Continue with the boolean approach, but do not have entries for
>> every
>> version; rather make use of the "default value" for majority of
>> cases,
>> and add the explicit version mapping for the minority e.g.
>> GlusterSupported = true by default, and false in case of 3.0 (only
>> one
>> 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 to 
understand.

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. I'm 
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 that 
another entry is added for 3.3-true. I think it is not logical as well 
as scalable if you have more versions. And it sounds far more complex 
(to maintain) than just having

<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.

>> Thoughts?
>>
>> Regards,
>> Shireesh
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>