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. 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
Re: [Engine-devel] FeatureSupported and compatibility versions
- 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
Re: [Engine-devel] FeatureSupported and compatibility versions
On 03/20/2013 04:47 PM, Shireesh Anjal wrote: Why are we even storing this information in config? Is this something that can be configured at customer site? some features can be disabled, and only enabled by someone aware of the implications of enabling them. that's apart of the versions they are supported at i guess ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] FeatureSupported and compatibility versions
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
Re: [Engine-devel] FeatureSupported and compatibility versions
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, 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
Re: [Engine-devel] FeatureSupported and compatibility versions
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 Anjal san...@redhat.com To: Mike Kolesnik mkole...@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, 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 FeatureSupportedFrom = 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. I've sent a patch (http://gerrit.ovirt.org/12970) with following changes: 1) Introduced CompatibilityUtils that provides utility methods for checking if a given feature is supported in the config. One method to check based on boolean values (as is being done today for virt features), and nother to check based on a range (from, to) which I would like to use for gluster features. 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use the first utility method from CompatibilityUtils 3) Introduced GlusterFeatureSupported for gluster features, which uses the second utility method from CompatibilityUtils Key advantage here is that - we don't have to touch any virt specifc source for adding compatibility checks for gluster features - virt features continue to use the existing boolean config check Any comments / suggestions / reviews will be highly appreciated :) I think splitting to two classes is OK, but the underlying mechanism IMO should be as Omer suggested: Use the default value from the java config file, and if in the DB there is a version specific value then use it for that version only. Review comments here are on the contrary: http://gerrit.ovirt.org/#/c/12970/5/backend/manager/dbscripts/upgrade/pre_upgrade/_config.sql I don't think From, To, etc is a good design, it's not a standard way and is very restrictive. Can you please explain in what way
Re: [Engine-devel] FeatureSupported and compatibility versions
On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: - Original Message - From: Shireesh Anjal san...@redhat.com To: Mike Kolesnik mkole...@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, 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 FeatureSupportedFrom = 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. I've sent a patch (http://gerrit.ovirt.org/12970) with following changes: 1) Introduced CompatibilityUtils that provides utility methods for checking if a given feature is supported in the config. One method to check based on boolean values (as is being done today for virt features), and nother to check based on a range (from, to) which I would like to use for gluster features. 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use the first utility method from CompatibilityUtils 3) Introduced GlusterFeatureSupported for gluster features, which uses the second utility method from CompatibilityUtils Key advantage here is that - we don't have to touch any virt specifc source for adding compatibility checks for gluster features - virt features continue to use the existing boolean config check Any comments / suggestions / reviews will be highly appreciated :) 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel
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 FeatureSupportedFrom = 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@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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] FeatureSupported and compatibility versions
- 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? 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
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 FeatureSupportedFrom = 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@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
Re: [Engine-devel] FeatureSupported and compatibility versions
- 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. 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. 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
