
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@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">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <br> </body> </html> --------------060202090604020609010600--