----- Original Message -----
From: "Shireesh Anjal" <sanjal@redhat.com> To: "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@ovirt.org 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 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
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 version". 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.
Thoughts?
Regards, Shireesh _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel