8:08 a.m.
------=_Part_43195740_1618344988.1385878122945
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
----- Original Message -----
=20
=20
=20
=20
Hi All,</blockquote><div><br></div><div>Hi
Kanagaraj,<br></div><div><br=
The are some issues arising in configurations whenever we
move up on
the versions(3.3 =3D> 3.4), because of the way we store and
interpret them.<br><br
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.<br=
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.<br><br Lets
take an exmaple, "SupportForceCreateVG" - This is supported
from 3.1 onwards,<br><br If
you look at config.sql, you will see following entries <br
select
fn_db_add_config_value('SupportForceCreateVG','false','3.0');
<br select
fn_db_add_config_value('SupportForceCreateVG','true','3.1');
<br select
fn_db_add_config_value('SupportForceCreateVG','true','3.2');
<br select
fn_db_add_config_value('SupportForceCreateVG','true','3.3');<br>=
<br And in ConfigValues.java<br><br
@TypeConverterAttribute(Boolean.class)<br
@DefaultValueAttribute("false")<br
SupportForceCreateVG,<br><br Now
if there is 3.4 and 3.5, the user needs to add 2 more entries,
which i feel is redundant.<br><br
Instead we can make <br><br
@TypeConverterAttribute(Boolean.class)<br
@DefaultValueAttribute("true")<br
SupportForceCreateVG,<br><br and have only the following in config.sql<br select
fn_db_add_config_value('SupportForceCreateVG','false','3.0');<br=
><br 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.</blockquote><div><br></div><div>This
has already bee=
n implemented, there are many "feature supported" configurations working li=
ke this (for example
GlusterSupport).<br></div><div><br></div><div>I think
=
a more interesting approach would be to move these out of the DB since thes=
e values don't really hav e a reson to be there.<br></div><div>Since
the en=
tire thing is abstracted by "Gluster/FeatureSupported" classes then we can =
easily change mechanism (of course whatever code is not using it can be eas=
ily converted to use the
mechanism)<br></div><div><br></div><div>For exampl=
e a simple enum could do the
trick:<br></div><div>-------------------------=
------------ EXAMPLE
-------------------------------------<br></div><div>/*=
*<br> * Convenience class to check if a gluster feature is supported o=
r not in any given version.<br><br> * Methods should be named
by=
feature and accept version to check against.<br> */<br>public class
G=
lusterFeatureSupported {</div><div>
/**<br> &n=
bsp; * @param version<br>
* =
Compatibility version to c=
heck for.<br> * @return
<code>true</code&g=
t; if gluster support is enabled, <code>false</code> if
it's no=
t.<br>
*/<br> public static boole=
an gluster(Version version)
{<br> =
return
SupportedFeatures.GLUSTER.isSupportedOn(version);<br> &n=
bsp; }<br><br>
/**<br> * @param v=
ersion<br>
* &nb=
sp; Compatibility version to check
for.<br> &n=
bsp; * @return <code>true</code> if
gluster heavywe=
ight refresh is enabled, <code>false</code> if it's
not.<br>&nb=
sp; */<br> public static
boolean refres=
hHeavyWeight(Version version)
{<br> &nbs=
p; return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);<br>=
}<br></div><div><br></div><div>
/* Mor=
e methods... */</div><div><br> enum
SupportedFeatures {<b=
r>
GLUSTER(Version.v3_0),<br>&nbs=
p;
REFRESH_HEAVYWEIGHT(Version.v3_0, Ve=
rsion.v3_1),</div><div>
/* More m=
embers
*/;<br><br>
private Set<=
;Version> unsupportedVersions =3D new
HashSet<Version>();<br><br>&=
nbsp; private
SupportedFeatures(Version=
... versions)
{<br> &n=
bsp;
unsupportedVersions.addAll(Arrays.asList(versions));<br> &n=
bsp;
}<br><br> &=
nbsp; public boolean isSupportedOn(Version version)
{<br> =
return !unsupportedV=
ersions.contains(version);<br>
}<=
br>
}</div><div>------------------------------------- END=
EXAMPLE
-------------------------------------</div><div><br></div><div>Tho=
ughts?<br></div><div><br></div><div>Regards,<br></div><div>Mike<br></div><b=
lockquote style=3D"border-left:2px solid #1010FF;margin-left:5px;padding-le=
ft:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none=
;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br Please share your thoughts on this.<br><br Thanks,<br
Kanagaraj<br><br></blockquote></div></body></html ------=_Part_43195740_1618344988.1385878122945--
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
------=_Part_43195740_1618344988.1385878122945
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color: #000000"><hr
id=3D"zwchr"><blockquote style=3D=
"border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;=
font-weight:normal;font-style:normal;text-decoration:none;font-family:Helve=
tica,Arial,sans-serif;font-size:12pt;"</div><blockquote style=3D"border-left:2px solid
#1010FF;margin-left:5px;p=
adding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decora=
tion:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br