The idea should be to make sure that maintaining the feature supported
matrix is not a nightmare. If we need to go and replicate entries in
_config.sql file for each new version, then this is an issue. And I
think we are all in agreement that this is not the way to go.
Either we go with
[1]. default value in ConfigValues, and only changed value in db script
like in patch set 5 (http://gerrit.ovirt.org/#/c/12970/5)
If this mechanism is broken, do you know where/what is broken?
or [2] . with the new approach where a Feature supported changes to
true/false **from** a particular version.
(I think, for gluster features, the Feature From works for us as we do
not see it changing from version to version once supported. )
But if there's a way to fix 1, let's do that to get this moving.
Mike, could you elaborate on what needs to be fixed in [1] ?
On 04/02/2013 04:30 PM, Shireesh Anjal wrote:
On 04/02/2013 02:47 PM, Mike Kolesnik wrote:
On 03/27/2013 05:48 PM, Mike Kolesnik wrote:
- Original Message -
On 03/20/2013 08:20 PM, Yair Zaslavsky wrote:
- Original Message -
From: Shireesh Anjalsan...@redhat.com
To: Mike Kolesnikmkole...@redhat.com
Cc:engine-devel@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?
As previously explained (but off list :) ) , Config gives you
the
ability to have a cachable map of entry (i.e - feature name)
per version and value.
I guess it was convinient for the developers to use that.
I also mentioned that customers/oVirt users should config the
entries of vdc_options using engine-config tool only.
Not all entries are exposed via engine-config.properties (and
no,
not just is feature supported entries are hidden).
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,
