11:02 a.m.
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: "Dusmant Kumar Pati" <dpati(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Saturday, November 30, 2013 10:58:35 PM
Subject: Re: [Engine-devel] Using config values
----- Original Message -----
> From: "Dusmant Kumar Pati" <dpati(a)redhat.com>
> To: "Kanagaraj" <kmayilsa(a)redhat.com>, "engine-devel"
> <engine-devel(a)ovirt.org>
> Sent: Friday, November 29, 2013 1:40:09 PM
> Subject: Re: [Engine-devel] Using config values
>
> 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.
Hi
First of all I think its a good idea
I have 2 questions
1) Which value will be stored as default in the java class for configuration
values that are not a boolean, that represents if a feature is active or
not.
Is that the latest version value ? sounds not obvious to me
i guess this will have to have a configuration values for each version in the db.
2) There are some configuration values that are exposed to the user
via the
engine-config tool, how this will work, we can not remove the entries their
since the user may change and override those values.
in your suggestion below, there is the same issue,
if user want to change the 3.3 value, engine config will fail with "No such
entry"
because 3.3 will not be in the db..
so if we are not fixing this, i think using the current implementation is good enough,
no need to add logic, just to convert current options that are not in this format, to use
this logic.
I have a different suggestion:
Default value will stay as is , meaning , it will reflect the value that
should be used to keep the application running correctly if a value is not
found in DB (which should not occur)
Code of getting configuration value (getConfigValue(<key>,<version>) will be
changed to get the closest version value to the given one.
For example , if a 3.4 version is given for a given <key> and we have in DB
just values for 3.0 and 3.1 , the 3.1 value is returned.
I prefer this solution since it makes the config.sql file self documented ,
showing only value changes and in which version each change occurred.
To implement that, we should add this mechanism to the current code that
caches the DB content and as I see that it should be a simple change.
engine-config should be modified such that if the user change a value, this
value will be inserted to the database with the current release if not
exists and then the mechanism described above will get this value
Example:
VdsFenceType lists all the supported fencing agents for power management , it
currently has the following settings
option_value
|
version
---------------------------------------------------------------------------------------------+---------
alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
| 3.0
alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
| 3.1
apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
| 3.2
apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
| 3.3
In the proposed solution, we will have
option_value
|
version
---------------------------------------------------------------------------------------------+---------
alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
| 3.0
apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
| 3.2
This is clear and documents only the changes done between versions and serve
all values: boolean , string and complex type (those which requires any kind
of parsing)
What do you think?
Eli
>
> Thanks,
> Kanagaraj
>
>
>
> _______________________________________________
> Engine-devel mailing list Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> I think, this is a good suggestion...
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel