----- Original Message -----
> Hi All,
Hi Kanagaraj,
> The are some issues arising in configurations whenever we move up on the
> versions(3.3 => 3.4), because of the way we store and interpret them.
> Whenever there is a new cluster level, you will need to add a new entry for
> all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
> 3.3, except some CPU/PM type related configurations.
> Better option would be to have the defaul config value in ConfigValues.java
> and the overrides will go to config.sql. In this approach you don't need a
> new entries to config.sql when there is a new cluster level.
> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> onwards,
> If you look at config.sql, you will see following entries
> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> And in ConfigValues.java
> @TypeConverterAttribute(Boolean.class)
> @DefaultValueAttribute("false")
> SupportForceCreateVG,
> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
> feel is redundant.
> Instead we can make
> @TypeConverterAttribute(Boolean.class)
> @DefaultValueAttribute("true")
> SupportForceCreateVG,
> and have only the following in config.sql
> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> if a particular value(for a specific cluster level) is not found in
> Config.sql, the fallback is to use the value available in ConfigValues.java.
This has already been implemented, there are many "feature supported"
configurations working like this (for example GlusterSupport).
I think a more interesting approach would be to move these out of the DB since
these values don't really hav e a reson to be there.
Since the entire thing is abstracted by "Gluster/FeatureSupported" classes then
we can easily change mechanism (of course whatever code is not using it can be
easily converted to use the mechanism)
For example a simple enum could do the trick:
------------------------------------- EXAMPLE
-------------------------------------
/**
* Convenience class to check if a gluster feature is supported or not in any
given version.<br>
* Methods should be named by feature and accept version to check against.
*/
public class GlusterFeatureSupported {
/**
* @param version
* Compatibility version to check for.
* @return <code>true</code> if gluster support is enabled, <code>false</code>
if it's not.
*/
public static boolean gluster(Version version) {
return SupportedFeatures.GLUSTER.isSupportedOn(version);
}
/**
* @param version
* Compatibility version to check for.
* @return <code>true</code> if gluster heavyweight refresh is enabled,
<code>false</code> if it's not.
*/
public static boolean refreshHeavyWeight(Version version) {
return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
}
/* More methods... */
enum SupportedFeatures {
GLUSTER(Version.v3_0),
REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
/* More members */;
private Set<Version> unsupportedVersions = new HashSet<Version>();
private SupportedFeatures(Version... versions) {
unsupportedVersions.addAll(Arrays.asList(versions));
}
public boolean isSupportedOn(Version version) {
return !unsupportedVersions.contains(version);
}
}
------------------------------------- END EXAMPLE
-------------------------------------
Thoughts?
Regards,
Mike
> Please share your thoughts on this.
> Thanks,
> Kanagaraj
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
