12:55 a.m.
On 10/09/12 00:58, Alon Bar-Lev wrote:
Hello All,
I would like to discuss the method we use to manage default options. I believe it can be
significantly simplified.
Please read though and comment.
Thank you,
Alon Bar-Lev
---
CURRENT STATE
Most options are located in three different locations.
Let's explain by example... The FenceQuietTimeBetweenOperationsInSec option.
---
ConfigValues.java
---
public enum ConfigValues {
<snip>
@Reloadable
@TypeConverterAttribute(Integer.class)
@DefaultValueAttribute("180")
FenceQuietTimeBetweenOperationsInSec(30),
<snip>
}
---
---
0000_config.sql
---
<snip>
select
fn_db_add_config_value('FenceQuietTimeBetweenOperationsInSec','180','general');
<snip>
---
---
engine-config.properties
---
<snip>
FenceQuietTimeBetweenOperationsInSec.type=Integer
FenceQuietTimeBetweenOperationsInSec.validValues=60..600
FenceQuietTimeBetweenOperationsInSec.description="Fence quiet time between
operations (in seconds)"
FenceQuietTimeBetweenOperationsInSec.alternateKey=Fence_Quiet_Time
<snip>
---
ConfigValues.java is the base, it defines all options and appropriate metadata as
annotations. It defines the option name, type, default value, and if reloadable.
0000_config.sql adds all parameters into the database using their default value, we
actually duplicate the parameter name and default value into the sql script. Please note
that even if we do not add the parameter to the database the engine infrastructure will
use the default value specify at ConfigValues.
engine-config.properties is used as an interface to engine-config utility, a command-line
utility that can manipulate engine options. engine-config manages only options that are
specified in this property files. Property files specifies user friendly description,
valid values, alias, but duplicate the option name and type that already specified in
ConfigValues. engine-config will only manage options that exists in database.
QUESTIONS
1. Why do we store default values in database?
Our intention so far was to remove default values from the code.
The values in the data base are not default values but the values of the
properties and we keep them per version were we need different values
per version.
The obvious advantage of keeping them in the DB vs. in code is they can
be changed with no compilation required and today you don't need to
restart the application for changing some of them (WIP).
From what I managed to gather, we store default values in database
under the assumption that we need to keep defaults when we upgrade from one version to
another.
However, in most cases when upgrading an application the new defaults should apply as
long as they were not overridden by user. Keeping old default as a new value is an
exception that can be taken care of during the upgrade process for selected options.
2. Why do we keep properties file?
The properties file primary use was to add translation/description for
each property. The reason we store it in the file was that at some point
we'll support multilingual description for each property.
In practice we could specify the metadata within the property files as annotations in
ConfigValues.java. So why do we actually need the properties file?
From what I managed to gather, we use the property file as an interface to support
personal, to allow adding/removing options exposed to the engine-config utility. An
addition of option to the property file exposes it.
SUGGESTED STATE
Establish a single place to manage options.
Do not store default values in database.
Provide alternate method of exposing internal options to engine-config utility.
Maintaining that in a single place would be great.
1. Were do you store the description of each property (and optionally
support multilingual)?
2. Where do you store value per version?
3. I personally find holding values in code cumbersome, usually you end
up with adding option to override the values by entries in the data
base.....
---
ConfigValues.java
---
public enum ConfigValues {
<snip>
@Reloadable
@Public
@TypeConverterAttribute(Integer.class)
@Restriction.IntegerRange(60, 600)
@DefaultValueAttribute("180")
@Description("Fence quiet time between operations (in seconds)")
FenceQuietTimeBetweenOperationsInSec(30),
<snip>
}
---
BENEFITS
No duplication of option name, type, default value, etc... between multiple files. One
place to role them all.
Simpler upgrade sequence, in most cases as we do want the new defaults to apply.
METHOD
1. Add @Public annotation for ConfigValues, to expose options to engine-config instead of
the properties file.
2. Add @Restrict annotation for ConfigValues, instead of validValues of properties file.
3. Add @Description annotation for ConfigValues, instead of description of properties
file.
4. Add engine-config --internal parameter to allow get/set/list of none @Public option,
instead of the need to update the properties file.
5. Modify enigne-config [set] to add option if does not exist in database and does not
match default value.
6. Modify engine-config [set] to delete option if value matches default value.
7. Modify engine-config [get] to retrieve default from ConfigValues if value is missing
from database.
8. Create upgrade script which deletes all options with value that matches the default
from the database.
IMPLICATIONS
The option alias is removed. Can be added at later time if required using own @Alias
annotation. Not sure it is actually required.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel