11:06 a.m.
This is a multi-part message in MIME format.
--------------060202090604020609010600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 11/29/2013 01:46 PM, Kanagaraj wrote:
Hi All,
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.
Please share your thoughts on this.
+1
Thanks,
Kanagaraj
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------060202090604020609010600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/29/2013 01:46 PM, Kanagaraj
wrote:<br>
</div>
<blockquote cite="mid:52984D48.1070009@redhat.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi All,<br>
<br>
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.<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.<br>
<br>
Please share your thoughts on this.<br>
</blockquote>
<br>
+1<br>
<br>
<blockquote cite="mid:52984D48.1070009@redhat.com"
type="cite"> <br>
Thanks,<br>
Kanagaraj<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<br>
</body>
</html>
--------------060202090604020609010600--