----- Original Message ----- > From: "Shireesh Anjal" <[email protected]> > To: "Mike Kolesnik" <[email protected]> > Cc: [email protected] > 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 > >> [email protected] > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
