Re: [Engine-devel] FeatureSupported and compatibility versions

From: "Shireesh Anjal" <sanjal(a)redhat.com&gt; To: "Mike Kolesnik" <mkolesni(a)redhat.com&gt; Cc: engine-devel(a)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

<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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel