[Engine-devel] FeatureSupported and compatibility versions

[Yair Zaslavsky]

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