[Engine-devel] Using config values

[Eli Mesika]

----- Original Message -----
> From: "Dusmant Kumar Pati" <dpati at redhat.com>
> To: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel" <engine-devel at 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 

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.

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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> I think, this is a good suggestion...
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>