Re: [Engine-devel] Using config values

----- Original Message ----- 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