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: Wednesday, March 20, 2013 4:47:08 PM Subject: Re: [Engine-devel] FeatureSupported and compatibility versions On 03/18/2013 01:11 PM, Shireesh Anjal wrote: > 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. Why are we even storing this information in config? Is this something that can be "configured" at customer site?

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