----- Original Message ----- > From: "Shireesh Anjal" <san...@redhat.com> > To: engine-devel@ovirt.org > Cc: "Omer Frenkel" <ofren...@redhat.com> > Sent: Thursday, May 2, 2013 1:03:23 PM > Subject: Re: [Engine-devel] FeatureSupported and compatibility versions > > On 03/18/2013 01:30 PM, Omer Frenkel wrote: > > > > ----- Original Message ----- > >> From: "Shireesh Anjal" <san...@redhat.com> > >> To: engine-devel@ovirt.org > >> Sent: Monday, March 18, 2013 8:28:14 AM > >> Subject: [Engine-devel] FeatureSupported and compatibility versions > >> > >> 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: > >> > >> 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 like this approach better, > > if one add new feature for 3.3 he should add it as 'true' in the config to > > be used as default, > > and explicitly add it as false for other unsupported versions. > > For the record, this was the approach that was finally approved on the > patch and merged (http://gerrit.ovirt.org/12970) > So I think now onwards, everyone can start using this approach for new > features being added. > > > if we do go this way, we need to make sure it works because i vaguely > > remember we had a bug in configuration, > > making us explicitly specify value for all versions. > > I wrote a test case on DBConfigUtils that verifies that it does indeed > work fine (http://gerrit.ovirt.org/13787), which has also been approved > and merged. >
Thanks! > > > >> 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