12:01 p.m.
------=_Part_43206801_1748816137.1385888510809
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
----- Original Message -----
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> To: "Kanagaraj" <kmayilsa(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Sunday, December 1, 2013 8:08:42 AM
> Subject: Re: [Engine-devel] Using config values
> ----- 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?
unless i didn't understand something, this is not good,
this should stay configurable by the users,
for example if some user experience some issues with a feature and want to
turn it off/change the values..
(not all version configuration are boolean, some are different values to
different versions, like cpu-list)
This is for API level compatibility.
If VDSM doesn't support for example hot plug in 3.1 then the user can't just
decide that it does and change it.
Also, this is not changeable by user since it's not exposed by engine-config (nor
should it be).
This is strictly for the engine-VDSM API compatibility, not for other configs which are
version specific.
> Regards,
> Mike
> > Please share your thoughts on this.
>
> > Thanks,
>
> > Kanagaraj
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
------=_Part_43206801_1748816137.1385888510809
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;" data-mce-style=3D"border-left: 2px s=
olid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight=
: normal; font-style: normal; text-decoration: none; font-family: Helvetica=
,Arial,sans-serif; font-size: 12pt;"><div style=3D"font-family: times new
r=
oman, new york, times, serif; font-size: 12pt; color: #000000" data-mce-sty=
le=3D"font-family: times new roman, new york, times, serif; font-size: 12pt=
; color:
#000000;"><div><br></div><div><br></div><hr
id=3D"zwchr"><blockquo=
te 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-f=
amily:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-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=
: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From:
</b>"Mike Kolesnik=
" &lt;mkolesni(a)redhat.com&gt;<br><b>To:
</b>"Kanagaraj" <kmayilsa@redhat=
.com><br><b>Cc: </b>"engine-devel"
&lt;engine-devel(a)ovirt.org&gt;<br><b>=
Sent: </b>Sunday, December 1, 2013 8:08:42 AM<br><b>Subject:
</b>Re: [Engin=
e-devel] Using config values<br><div><br></div><div
style=3D"font-family: t=
imes new roman, new york, times, serif; font-size: 12pt; color: #000000" da=
ta-mce-style=3D"font-family: times new roman, new york, times, serif; font-=
size: 12pt; color: #000000;"><hr id=3D"zwchr"><blockquote
style=3D"border-l=
eft:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weig=
ht:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Aria=
l,sans-serif;font-size:12pt;" data-mce-style=3D"border-left: 2px solid #101=
0FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal;=
font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sa=
ns-serif; font-size: 12pt;">Hi
All,</blockquote><div><br></div><div>Hi Kana=
garaj,<br></div><div><br></div><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:Helvetica,Arial,sans-serif;fo=
nt-size:12pt;" data-mce-style=3D"border-left: 2px solid #1010FF; margin-lef=
t: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: no=
rmal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-=
size: 12pt;"><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><div><br></div>Whenever there is a new cluster
level, yo=
u 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 con=
figurations.<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 lev=
el.<br><div><br></div>Lets take an exmaple,
"SupportForceCreateVG" - This i=
s supported from 3.1 onwards,<br><div><br></div>If you look at
config.sql, =
you will see following entries <br> select fn_db_add_config_value('SupportF=
orceCreateVG','false','3.0'); <br> select
fn_db_add_config_value('SupportFo=
rceCreateVG','true','3.1'); <br> select
fn_db_add_config_value('SupportForc=
eCreateVG','true','3.2'); <br> select
fn_db_add_config_value('SupportForceC=
reateVG','true','3.3');<br><div><br></div>And
in ConfigValues.java<br><div>=
<br></div>
@TypeConverterAttribute(Boolean.class)<br> &nb=
sp; @DefaultValueAttribute("false")<br>
Supp=
ortForceCreateVG,<br><div><br></div>Now if there is 3.4 and 3.5,
the user n=
eeds to add 2 more entries, which i feel is
redundant.<br><div><br></div>In=
stead we can make
<br><div><br></div>
@TypeConverterAttri=
bute(Boolean.class)<br>
@DefaultValueAttribute("true")<b=
r>
SupportForceCreateVG,<br><div><br></div>and have only=
the following in config.sql<br> select fn_db_add_config_value('SupportForc=
eCreateVG','false','3.0');<br><div><br></div>if
a particular value(for a sp=
ecific cluster level) is not found in Config.sql, the fallback is to use th=
e value available in
ConfigValues.java.</blockquote><div><br></div><div>Thi=
s has already been implemented, there are many "feature supported" configur=
ations working like 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 these values don't really hav e a reson to be
there.<br></div>=
<div>Since the entire thing is abstracted by "Gluster/FeatureSupported"
cla=
sses then we can easily change mechanism (of course whatever code is not us=
ing it can be easily converted to use the
mechanism)<br></div><div><br></di=
v><div>For example a simple enum could do the
trick:<br></div><div>--------=
----------------------------- EXAMPLE -------------------------------------=
<br></div><div>/**<br> * Convenience class to check if a
gluster featu=
re is supported or not in any given version.<br><br> *
Methods s=
hould be named by feature and accept version to check against.<br> */<=
br>public class GlusterFeatureSupported
{</div><div> /**<=
br> * @param
version<br> *&=
nbsp;
Compatibi=
lity version to check for.<br> * @return
<code&g=
t;true</code> if gluster support is enabled,
<code>false</co=
de> if it's not.<br>
*/<br> pu=
blic static boolean gluster(Version version)
{<br> &=
nbsp; return SupportedFeatures.GLUSTER.isSupportedOn(version);<=
br>
}<br><div><br></div>
/**<br> &=
nbsp; * @param
version<br> *  =
;
Compatibility versi=
on to check for.<br> * @return
<code>true<=
/code> if gluster heavyweight refresh is enabled,
<code>false</=
code> if it's not.<br>
*/<br> =
public static boolean refreshHeavyWeight(Version version)
{<br> =
return
SupportedFeatures.REFRESH_HEAVYWEIGHT=
.isSupportedOn(version);<br>
}<br></div><div><br></div><d=
iv> /* More methods...
*/</div><div><br>  =
; enum SupportedFeatures
{<br> GL=
USTER(Version.v3_0),<br>
REFRESH_=
HEAVYWEIGHT(Version.v3_0,
Version.v3_1),</div><div> =
/* More members
*/;<br><div><br></div> =
private Set<Version>
unsupportedVersions =3D=
new
HashSet<Version>();<br><div><br></div> &n=
bsp; private SupportedFeatures(Version... versions)
{<br> =
unsupportedVer=
sions.addAll(Arrays.asList(versions));<br> &nb=
sp;
}<br><div><br></div>
pu=
blic boolean isSupportedOn(Version version)
{<br> &n=
bsp; return
!unsupportedVersions.contai=
ns(version);<br>
}<br>  =
; }</div><div>------------------------------------- END EXAMPLE
-----=
--------------------------------</div><div><br></div><div>Thoughts?</div></=
div></blockquote><div><br>unless i didn't understand something,
this is not=
good,<br></div><div>this should stay configurable by the
users,<br></div><=
div>for example if some user experience some issues with a feature and want=
to turn it off/change the values..</div><div>(not all version configuratio=
n are boolean, some are different values to different versions, like cpu-li=
st)</div></div></blockquote><div><br></div><div>This
is for API level compa=
tibility.<br></div><div>If VDSM doesn't support for example hot plug
in 3.1=
then the user can't just decide that it does and change
it.<br></div><div>=
Also, this is not changeable by user since it's not exposed by engine-confi=
g (nor should it
be).<br></div><div><br></div><div>This is strictly for
the=
engine-VDSM API compatibility, not for other configs which are version spe=
cific.<br></div><div><br></div><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:Helvetica,Arial,sans-serif;fo=
nt-size:12pt;" data-mce-style=3D"border-left: 2px solid #1010FF; margin-lef=
t: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: no=
rmal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-=
size: 12pt;"><div style=3D"font-family: times new roman, new york, times,
s=
erif; font-size: 12pt; color: #000000" data-mce-style=3D"font-family: times=
new roman, new york, times, serif; font-size: 12pt; color:
#000000;"><div>=
<br></div><blockquote style=3D"border-left:2px solid
#1010FF;margin-left:5p=
x;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-dec=
oration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-m=
ce-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: Helvetica,Arial,sans-serif; font-size: 12pt;"><div sty=
le=3D"font-family: times new roman, new york, times, serif; font-size: 12pt=
; color: #000000" data-mce-style=3D"font-family: times new roman, new york,=
times, serif; font-size: 12pt; color:
#000000;"><div><br></div><div><br></=
div><div>Regards,<br></div><div>Mike<br></div><blockquote
style=3D"border-l=
eft:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weig=
ht:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Aria=
l,sans-serif;font-size:12pt;" data-mce-style=3D"border-left: 2px solid #101=
0FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal;=
font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sa=
ns-serif; font-size: 12pt;"><br> Please share your thoughts on
this.<br><di=
v><br></div>Thanks,<br>
Kanagaraj<br><div><br></div></blockquote></div><br>=
_______________________________________________<br>Engine-devel mailing lis=
t<br>Engine-devel@ovirt.org<br>http://lists.ovirt.org/mailman/listinfo/engi=
ne-devel<br></blockquote><div><br></div></div></blockquote><div><br></div><=
/div></body></html>
------=_Part_43206801_1748816137.1385888510809--