12:58 a.m.
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?
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?
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.
---
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.
8:22 a.m.
On 09/10/2012 12:58 AM, 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?
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?
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.
---
ConfigValues.java
---
public enum ConfigValues {
<snip>
@Reloadable
@Public
@TypeConverterAttribute(Integer.class)
@Restriction.IntegerRange(60, 600)
This definition will probably not work,
should be
@IntegerRestrictionRange(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.
I would still recommend in this case to have an optional properties file
that will allow you to override the behaviour of the @Public annotation
(i.e - cancel it).
In evolution of java frameworks from the stage where metadata was
provided via external configuration file (XML, properties file ,etc...)
to a stage where metadata was provided via annotations, in order to
support changes at metadata without needing to recompile and to support
backward compatibility, many frameworks simply made the configuration
file to be optional for purpose of overriding the annotation deceleration
2. Add @Restrict annotation for ConfigValues, instead of validValues of properties file.
Bare in mind that annotations are limited in the values they can accept.
Most likely it will work, but we need to check it.
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.
I would recommend as a future feature to consider modifying [set] to
provide an option to reset the value to the default value, as presented
at ConfigValue
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
11:04 a.m.
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Monday, September 10, 2012 8:22:11 AM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
On 09/10/2012 12:58 AM, 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?
>
> 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?
>
> 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.
>
> ---
> ConfigValues.java
> ---
> public enum ConfigValues {
> <snip>
> @Reloadable
> @Public
> @TypeConverterAttribute(Integer.class)
> @Restriction.IntegerRange(60, 600)
This definition will probably not work, should be
@IntegerRestrictionRange(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.
I would still recommend in this case to have an optional properties
file
that will allow you to override the behaviour of the @Public
annotation
(i.e - cancel it).
Why would you want to cancel it?
I understand why you want to expose more...
But cancel?
I don't mind adding a /etc/<something> to allow exposing more, but why adding
--internal parameter to engine-config is not enough?
In evolution of java frameworks from the stage where metadata was
provided via external configuration file (XML, properties file
,etc...)
to a stage where metadata was provided via annotations, in order to
support changes at metadata without needing to recompile and to
support
backward compatibility, many frameworks simply made the configuration
file to be optional for purpose of overriding the annotation
deceleration
I don't mind to use XML for holding metadata, or any format, as long as we have single
location to declare new option.
We can even use a table within database...
*BUT* the metadata should be in one place, and there should be no default values within
the options tables so an update to the metadata will be in effect as long as the user had
not overridden the default.
>
> 2. Add @Restrict annotation for ConfigValues, instead of
> validValues of properties file.
Bare in mind that annotations are limited in the values they can
accept.
Most likely it will work, but we need to check it.
Sure...
>
> 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.
I would recommend as a future feature to consider modifying [set] to
provide an option to reset the value to the default value, as
presented
at ConfigValue
Good idea! so we can have --set "[default]" or similar to revert to default
value.
>
> 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
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8: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
9:04 a.m.
On 09/10/2012 08:55 AM, Livnat Peer wrote:
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).
you can still change them in the db without code by overriding them in
the db - code is just the default if there is no value in the db, right?
9:05 a.m.
On 09/10/2012 09:04 AM, Itamar Heim wrote:
On 09/10/2012 08:55 AM, Livnat Peer wrote:
> 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).
you can still change them in the db without code by overriding them in
the db - code is just the default if there is no value in the db, right?
Yes, you also get a warning message indicating they cannot be found, so
the default value is used.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:09 a.m.
On 09/10/2012 09:05 AM, Yair Zaslavsky wrote:
On 09/10/2012 09:04 AM, Itamar Heim wrote:
> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>> 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).
>
> you can still change them in the db without code by overriding them in
> the db - code is just the default if there is no value in the db, right?
Yes, you also get a warning message indicating they cannot be found, so
the default value is used.
if we remove the defaults from the db for those that don't have per
version values, i don't think we'll want that warning in the log not in
debug mode...
9:34 a.m.
On 09/10/2012 09:09 AM, Itamar Heim wrote:
On 09/10/2012 09:05 AM, Yair Zaslavsky wrote:
>
>
> On 09/10/2012 09:04 AM, Itamar Heim wrote:
>> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>>> 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).
>>
>> you can still change them in the db without code by overriding them in
>> the db - code is just the default if there is no value in the db, right?
>
> Yes, you also get a warning message indicating they cannot be found, so
> the default value is used.
if we remove the defaults from the db for those that don't have per
version values, i don't think we'll want that warning in the log not in
debug mode...
I agree.
9:19 a.m.
On 10/09/12 09:04, Itamar Heim wrote:
On 09/10/2012 08:55 AM, Livnat Peer wrote:
> 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).
you can still change them in the db without code by overriding them in
the db - code is just the default if there is no value in the db, right?
copy paste from my previous mail -
"
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.....
"
if you are going to maintain a table in the data base why start with
code from the first place....
9:30 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Monday, September 10, 2012 9:19:00 AM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
On 10/09/12 09:04, Itamar Heim wrote:
> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>> 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).
>
> you can still change them in the db without code by overriding them
> in
> the db - code is just the default if there is no value in the db,
> right?
>
copy paste from my previous mail -
"
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.....
"
if you are going to maintain a table in the data base why start with
code from the first place....
Because upgrading an application becomes more complex, as you need not only install
application binaries (rpm), but also touch the database.
Touching the database is a failure potential.
I will get back to your previous response later, just wanted to quick comment this one.
However, if you believe that any option needs to be in database, then the metadata
(description, restriction, internal flag, type, default) should also be moved to the
database, into its own table, so that vdc_options will not contain any default, so that
application can enjoy modifying defaults upon upgrade, and there will be no duplicate
between code and database.
Microsoft "Registry" is a good example of application options handling. The
"Registry" holds only non-default values, allowing the application to evolve
(both in term of more variables and in term of different defaults), without actually
touching the "Registry".
Alon.
10:01 a.m.
On 10/09/12 09:30, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Monday, September 10, 2012 9:19:00 AM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
>
> On 10/09/12 09:04, Itamar Heim wrote:
>> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>>> 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).
>>
>> you can still change them in the db without code by overriding them
>> in
>> the db - code is just the default if there is no value in the db,
>> right?
>>
>
> copy paste from my previous mail -
>
> "
> 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.....
> "
>
> if you are going to maintain a table in the data base why start with
> code from the first place....
>
>
Because upgrading an application becomes more complex, as you need not only install
application binaries (rpm), but also touch the database.
I don't think you can avoid upgrading the data base, regardless of the
the configuration table.
Touching the database is a failure potential.
I will get back to your previous response later, just wanted to quick comment this one.
However, if you believe that any option needs to be in database, then the metadata
(description, restriction, internal flag, type, default) should also be moved to the
database, into its own table, so that vdc_options will not contain any default, so that
application can enjoy modifying defaults upon upgrade, and there will be no duplicate
between code and database.
I would like to have everything stored in the data base.
We just need to do it (which we did not have time to do so far) and we
need to think of solution for the description field,(multilingual
support is typically done via properties file).
Microsoft "Registry" is a good example of application
options handling. The "Registry" holds only non-default values, allowing the
application to evolve (both in term of more variables and in term of different defaults),
without actually touching the "Registry".
Alon.
11:30 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, September 10, 2012 8:55:32 AM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
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).
The above statement is true if you use database or any other format, such as XML file for
the metadata.
As long as there is no duplication between code and metadata storage, and as long as the
default values are not stored within the options tables, so that after upgrade the new
defaults are in effect unless explicitly overridden by user.
Let's assume we would like to avoid compilation. What is the benefit in storing the
metadata within the database and not in plain text file / XML file / properties file?
> 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.
Usually, multilingual has the "C" (latin) within code, while overriding the
"other" lingual within language support pack. So that application without any
language support pack will speak latin.
The properties file also contains non multilingual items: restrictions and alias, so if
the propose is to be lingual, it should contain only description.
>
> 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)?
Description (non C multi-lingual) should be separate from other (operative) metadata.
The C (latin) description should be placed within core product metadata. Each other
supported linual should be within its own separate file.
This way you install ovirt-engine-lang-pack-es and application speaks es without change in
database or any of the installed files.
The search path for description is (1) use application locale, and if not found (2) use
the C locale. So when no description available at language pack, the core C is used.
2. Where do you store value per version?
When user set value it will be in database no change in that.
The question is where we keep the metadata.
We can keep the metadata within ConfigValues as annotations.
We can keep the metadata within XML or whatever format.
We can keep the metadata in *SEPARATE* table in database.
The benefit of using XML is that you can have one common metadata and one per product
variant. So that metadata search path can be (1) product variant, and if not found (2) use
the common metadata.
Same logic can be used within database only that it will be somewhat more complex to
implement.
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.....
Right,
This is what default is all about.
However, when introducing a new variable, the database is left as-is.
When changing default value that was not overridden by user, the database is left as-is.
And... as time goes by, developers collect the common use case, to apply into next
version, reducing the need to override defaults.
I would like to have everything stored in the data base.
We just need to do it (which we did not have time to do so far) and
we
need to think of solution for the description field,(multilingual
support is typically done via properties file).
I am curios to read why database is better mechanism for static metadata than plain XML.
> ---
> 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
>
1:28 p.m.
On 10/09/12 11:30, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Monday, September 10, 2012 8:55:32 AM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
>
> 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).
The above statement is true if you use database or any other format, such as XML file for
the metadata.
As long as there is no duplication between code and metadata storage, and as long as the
default values are not stored within the options tables, so that after upgrade the new
defaults are in effect unless explicitly overridden by user.
Let's assume we would like to avoid compilation. What is the benefit in storing the
metadata within the database and not in plain text file / XML file / properties file?
I think that the main advantage of using data base over XML is that we
already maintain data base and work with it. I have nothing against XML
but I think the question we should ask ourselves is why add another
mechanism like XML file for managing static configuration when we can
use data base?
Also I think there was/is a thought to expose the configuration via the
UI (both for view and edit) I think that if this is still the intention
then working with DB would be easier than XML.
>> 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.
Usually, multilingual has the "C" (latin) within code, while overriding the
"other" lingual within language support pack. So that application without any
language support pack will speak latin.
That's not the way I am familiar with, Usually when you work in java you
use ResourceBundle which uses keys in the code and the translation is
provided in external properties file, one per language, distinguished by
their extensions: sample.property.en sample.property.jp etc.
The properties file also contains non multilingual items:
restrictions and alias, so if the propose is to be lingual, it should contain only
description.
I agree.
>>
>> 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)?
Description (non C multi-lingual) should be separate from other (operative) metadata.
The C (latin) description should be placed within core product metadata. Each other
supported linual should be within its own separate file.
This way you install ovirt-engine-lang-pack-es and application speaks es without change
in database or any of the installed files.
The search path for description is (1) use application locale, and if not found (2) use
the C locale. So when no description available at language pack, the core C is used.
> 2. Where do you store value per version?
When user set value it will be in database no change in that.
The question is where we keep the metadata.
We can keep the metadata within ConfigValues as annotations.
We can keep the metadata within XML or whatever format.
We can keep the metadata in *SEPARATE* table in database.
The benefit of using XML is that you can have one common metadata and one per product
variant. So that metadata search path can be (1) product variant, and if not found (2) use
the common metadata.
Same logic can be used within database only that it will be somewhat more complex to
implement.
> 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.....
Right,
This is what default is all about.
However, when introducing a new variable, the database is left as-is.
When changing default value that was not overridden by user, the database is left as-is.
And... as time goes by, developers collect the common use case, to apply into next
version, reducing the need to override defaults.
> I would like to have everything stored in the data base.
> We just need to do it (which we did not have time to do so far) and
> we
> need to think of solution for the description field,(multilingual
> support is typically done via properties file).
I am curios to read why database is better mechanism for static metadata than plain XML.
>
>> ---
>> 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
>>
>
>
12:40 p.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Tuesday, September 11, 2012 1:28:46 PM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
<snip>
>>> 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).
>
> The above statement is true if you use database or any other
> format, such as XML file for the metadata.
>
> As long as there is no duplication between code and metadata
> storage, and as long as the default values are not stored within
> the options tables, so that after upgrade the new defaults are in
> effect unless explicitly overridden by user.
>
> Let's assume we would like to avoid compilation. What is the
> benefit in storing the metadata within the database and not in
> plain text file / XML file / properties file?
I think that the main advantage of using data base over XML is that
we
already maintain data base and work with it. I have nothing against
XML
but I think the question we should ask ourselves is why add another
mechanism like XML file for managing static configuration when we can
use data base?
Because:
1. During upgrade database is not touched, less chance of failure.
2. A patch that adds a new option is touching a single file.
It is obvious why if we use Java annotations....
And I will answer the obvious question of why single file if it is XML... still need
ConfigValues like enums... The answer is that we generate ConfigValues.java (just the enum
name) during build.
3. When using SQL database, the schema should be modified when each new feature /
restriction is introduced, while XML or code annotations are more flexible in this
regards.
4. The metadata of options (or any release dependent metadata) is unchanged between one
release to another, RDBMS role is to manage the data that is to be modified.
Also I think there was/is a thought to expose the configuration via
the
UI (both for view and edit) I think that if this is still the
intention
then working with DB would be easier than XML.
As all options are to be loaded to memory at initialization time, I don't think there
is any difference.
Please note that there are two entities:
- options' metadata
- options' values
The options' values is stored in database, I have no intention to change this.
The options' metadata is the one we are discussing.
Options' metadata can be read to memory to appropriate data format from XML or from
database, the end result is the same, there should be no difference for the consumer were
you got the metadata from.
>
>>> 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.
>
> Usually, multilingual has the "C" (latin) within code, while
> overriding the "other" lingual within language support pack. So
> that application without any language support pack will speak
> latin.
>
That's not the way I am familiar with, Usually when you work in java
you
use ResourceBundle which uses keys in the code and the translation is
provided in external properties file, one per language, distinguished
by
their extensions: sample.property.en sample.property.jp etc.
I prefer to use multiple properties files so that a language pack can be maintained and
installed separately.
ResourceBundle.getBundle() supports this as far as I understand.
Having said that, I still like to encourage the modification of single file when adding
one entity, much easier in review process, conflicts, code management, blame management,
learning curve etc...
So ether generate the C linguas property file during build time from java annotations or
XML metadata, and allow external linguas properties file to be added at later time.
Or maintain the translation within the metadata XML (this is the first true advantage of
storing metadata within XML over storing metadata using java annotations), and either
generate the linguas property files at built time, or just read it and create
ResourceBundle at runtime when reading the metadata (I think this is the simplest
solution).
<snip>
Thanks,
Alon
3:48 p.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Livnat Peer" <lpeer(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Wednesday, September 12, 2012 12:40:03 PM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Tuesday, September 11, 2012 1:28:46 PM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
> options
>
<snip>
> >>> QUESTIONS
> >>>
> >>> 1. Why do we store default values in database?
I wanted to add few important points
a) We have default values in DB in order to enable overriding values in the
0000_config.sql file only if a customer did not change the default value, if a customer
changed the default in some entries, we want to honour the customer settings
b)There may be other requirements on configuration that are easier to manage in the
database, for example, I have heard that one of the suggested features regarding
configuration is to keep a kind of configuration history and know exactly which
configuration values was changed, when and by whom.
c) The version mechanism in the config is working like this : there is a 'general'
version , means that this value is not version dependant, or the version can be a real
version like 3.1 3.2 etc , in such case the value is version dependant and an entry is
required for each version.
I agree however, that the default value in the code is redundant and error prone and
should be removed.
> >>>
> >>
> >> 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).
> >
> > The above statement is true if you use database or any other
> > format, such as XML file for the metadata.
> >
> > As long as there is no duplication between code and metadata
> > storage, and as long as the default values are not stored within
> > the options tables, so that after upgrade the new defaults are in
> > effect unless explicitly overridden by user.
> >
> > Let's assume we would like to avoid compilation. What is the
> > benefit in storing the metadata within the database and not in
> > plain text file / XML file / properties file?
>
> I think that the main advantage of using data base over XML is that
> we
> already maintain data base and work with it. I have nothing against
> XML
> but I think the question we should ask ourselves is why add another
> mechanism like XML file for managing static configuration when we
> can
> use data base?
Because:
1. During upgrade database is not touched, less chance of failure.
2. A patch that adds a new option is touching a single file.
It is obvious why if we use Java annotations....
And I will answer the obvious question of why single file if it is
XML... still need ConfigValues like enums... The answer is that we
generate ConfigValues.java (just the enum name) during build.
3. When using SQL database, the schema should be modified when each
new feature / restriction is introduced, while XML or code
annotations are more flexible in this regards.
4. The metadata of options (or any release dependent metadata) is
unchanged between one release to another, RDBMS role is to manage
the data that is to be modified.
> Also I think there was/is a thought to expose the configuration via
> the
> UI (both for view and edit) I think that if this is still the
> intention
> then working with DB would be easier than XML.
As all options are to be loaded to memory at initialization time, I
don't think there is any difference.
Please note that there are two entities:
- options' metadata
- options' values
The options' values is stored in database, I have no intention to
change this.
The options' metadata is the one we are discussing.
Options' metadata can be read to memory to appropriate data format
from XML or from database, the end result is the same, there should
be no difference for the consumer were you got the metadata from.
>
> >
> >>> 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.
> >
> > Usually, multilingual has the "C" (latin) within code, while
> > overriding the "other" lingual within language support pack. So
> > that application without any language support pack will speak
> > latin.
> >
> That's not the way I am familiar with, Usually when you work in
> java
> you
> use ResourceBundle which uses keys in the code and the translation
> is
> provided in external properties file, one per language,
> distinguished
> by
> their extensions: sample.property.en sample.property.jp etc.
I prefer to use multiple properties files so that a language pack can
be maintained and installed separately.
ResourceBundle.getBundle() supports this as far as I understand.
Having said that, I still like to encourage the modification of
single file when adding one entity, much easier in review process,
conflicts, code management, blame management, learning curve etc...
So ether generate the C linguas property file during build time from
java annotations or XML metadata, and allow external linguas
properties file to be added at later time.
Or maintain the translation within the metadata XML (this is the
first true advantage of storing metadata within XML over storing
metadata using java annotations), and either generate the linguas
property files at built time, or just read it and create
ResourceBundle at runtime when reading the metadata (I think this is
the simplest solution).
<snip>
Thanks,
Alon
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:57 p.m.
Hello Eli,
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
Sent: Wednesday, September 12, 2012 3:48:00 PM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
> > >>> QUESTIONS
> > >>>
> > >>> 1. Why do we store default values in database?
I wanted to add few important points
a) We have default values in DB in order to enable overriding values
in the 0000_config.sql file only if a customer did not change the
default value, if a customer changed the default in some entries, we
want to honour the customer settings
Default != value.
Default is what should be used if not specified explicitly
Current implementation puts the default value as a value, so you cannot distinguish
between what user enforced.
When a default is changed, because of field feedback, we should push this into the
database instead of keeping in database only options that were modified by the user and
fetch the default from the option metadata.
In another words.... there should be no 000_config.sql, the option table should be empty
as long as the user does not modify any of the options.
b)There may be other requirements on configuration that are easier
to
manage in the database, for example, I have heard that one of the
suggested features regarding configuration is to keep a kind of
configuration history and know exactly which configuration values
was changed, when and by whom.
There is no conflict. You can have audit table when modifying options.
Keep in mind that I discuss the option metadata.
I believe you are discussing the option data.
c) The version mechanism in the config is working like this : there
is a 'general' version , means that this value is not version
dependant, or the version can be a real version like 3.1 3.2 etc ,
in such case the value is version dependant and an entry is required
for each version.
Again, there is no conflict, as the default value within the metadata can be version
specific too.
Having said that, I don't understand how two different versions can work with the
different data models and share one database and options.
I agree however, that the default value in the code is redundant and
error prone and should be removed.
From what you wrote above, I don't understand how you reached to
this conclusion. Can you please explain?
Thanks,
Alon.
10:46 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
Sent: Wednesday, September 12, 2012 3:57:13 PM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
Hello Eli,
----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
> Sent: Wednesday, September 12, 2012 3:48:00 PM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
> options
>
> > > >>> QUESTIONS
> > > >>>
> > > >>> 1. Why do we store default values in database?
>
> I wanted to add few important points
> a) We have default values in DB in order to enable overriding
> values
> in the 0000_config.sql file only if a customer did not change the
> default value, if a customer changed the default in some entries,
> we
> want to honour the customer settings
Default != value.
Default is what should be used if not specified explicitly
Current implementation puts the default value as a value, so you
cannot distinguish between what user enforced.
When a default is changed, because of field feedback, we should push
this into the database instead of keeping in database only options
that were modified by the user and fetch the default from the option
metadata.
In another words.... there should be no 000_config.sql, the option
table should be empty as long as the user does not modify any of the
options.
Lets assume that we are going for it, how would you upgrade from the current state to your
suggested solution keeping all user current settings ?
> b)There may be other requirements on configuration that are
easier
> to
> manage in the database, for example, I have heard that one of the
> suggested features regarding configuration is to keep a kind of
> configuration history and know exactly which configuration values
> was changed, when and by whom.
There is no conflict. You can have audit table when modifying
options.
Keep in mind that I discuss the option metadata.
I believe you are discussing the option data.
You are right
> c) The version mechanism in the config is working like this : there
> is a 'general' version , means that this value is not version
> dependant, or the version can be a real version like 3.1 3.2 etc ,
> in such case the value is version dependant and an entry is
> required
> for each version.
Again, there is no conflict, as the default value within the metadata
can be version specific too.
I agree , however we should consider all changes in
current code + tools + upgrade since this seems a major change
Having said that, I don't understand how two different versions can
work with the different data models and share one database and
options.
> I agree however, that the default value in the code is redundant
> and
> error prone and should be removed.
From what you wrote above, I don't understand how you reached to this
conclusion. Can you please explain?
I mean that we have now defaults in code
(ConfigValues.java) and in the database they may not match.
I think as you that only one place defined the defaults, so , it should be removed from
code which is less flexible if we want to change something without recompiling ...
Thanks,
Alon.
11:36 a.m.
----- Original Message -----
From: "Eli Mesika" <emesika(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
Sent: Thursday, September 13, 2012 10:46:41 AM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Eli Mesika" <emesika(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
> Sent: Wednesday, September 12, 2012 3:57:13 PM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
> options
>
>
> Hello Eli,
>
> ----- Original Message -----
> > From: "Eli Mesika" <emesika(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
> > Sent: Wednesday, September 12, 2012 3:48:00 PM
> > Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
> > default
> > options
> >
> > > > >>> QUESTIONS
> > > > >>>
> > > > >>> 1. Why do we store default values in database?
> >
> > I wanted to add few important points
> > a) We have default values in DB in order to enable overriding
> > values
> > in the 0000_config.sql file only if a customer did not change the
> > default value, if a customer changed the default in some entries,
> > we
> > want to honour the customer settings
>
> Default != value.
> Default is what should be used if not specified explicitly
>
> Current implementation puts the default value as a value, so you
> cannot distinguish between what user enforced.
>
> When a default is changed, because of field feedback, we should
> push
> this into the database instead of keeping in database only options
> that were modified by the user and fetch the default from the
> option
> metadata.
>
> In another words.... there should be no 000_config.sql, the option
> table should be empty as long as the user does not modify any of
> the
> options.
>
Lets assume that we are going for it, how would you upgrade from the
current state to your suggested solution keeping all user current
settings ?
Either by:
1. leaving all existing data within database... so current users will not enjoy updating
defaults in future. I really don't like this solution, but it will work.
2. during upgrade, go over the values, and remove all that matches the metadata default.
This way, future change in metadata will apply.
> > b)There may be other requirements on configuration that are
> > easier
> > to
> > manage in the database, for example, I have heard that one of the
> > suggested features regarding configuration is to keep a kind of
> > configuration history and know exactly which configuration values
> > was changed, when and by whom.
>
> There is no conflict. You can have audit table when modifying
> options.
> Keep in mind that I discuss the option metadata.
> I believe you are discussing the option data.
You are right
>
> > c) The version mechanism in the config is working like this :
> > there
> > is a 'general' version , means that this value is not version
> > dependant, or the version can be a real version like 3.1 3.2 etc
> > ,
> > in such case the value is version dependant and an entry is
> > required
> > for each version.
>
> Again, there is no conflict, as the default value within the
> metadata
> can be version specific too.
I agree , however we should consider all changes in current code +
tools + upgrade since this seems a major change
Right. I outlined all changes I collected in the initial message.
>
> Having said that, I don't understand how two different versions can
> work with the different data models and share one database and
> options.
>
> > I agree however, that the default value in the code is redundant
> > and
> > error prone and should be removed.
>
> From what you wrote above, I don't understand how you reached to
> this
> conclusion. Can you please explain?
I mean that we have now defaults in code (ConfigValues.java) and in
the database they may not match.
I think as you that only one place defined the defaults, so , it
should be removed from code which is less flexible if we want to
change something without recompiling ...
If we decide to use java annotations for metadata, the default will be in annotation.
If we decide to use XML for metadata, the default will be in XML.
At any case, I would like to reach to a state where the metadata is at one place, and not
spread between code, property/xml, database.
Thanks,
Alon
5:50 p.m.
On 09/13/2012 11:36 AM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
> Sent: Thursday, September 13, 2012 10:46:41 AM
> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
>
>
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> To: "Eli Mesika" <emesika(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
>> Sent: Wednesday, September 12, 2012 3:57:13 PM
>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
>> options
>>
>>
>> Hello Eli,
>>
>> ----- Original Message -----
>>> From: "Eli Mesika" <emesika(a)redhat.com>
>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
>>> Sent: Wednesday, September 12, 2012 3:48:00 PM
>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>> default
>>> options
>>>
>>>>>>>> QUESTIONS
>>>>>>>>
>>>>>>>> 1. Why do we store default values in database?
>>>
>>> I wanted to add few important points
>>> a) We have default values in DB in order to enable overriding
>>> values
>>> in the 0000_config.sql file only if a customer did not change the
>>> default value, if a customer changed the default in some entries,
>>> we
>>> want to honour the customer settings
>>
>> Default != value.
>> Default is what should be used if not specified explicitly
>>
>> Current implementation puts the default value as a value, so you
>> cannot distinguish between what user enforced.
>>
>> When a default is changed, because of field feedback, we should
>> push
>> this into the database instead of keeping in database only options
>> that were modified by the user and fetch the default from the
>> option
>> metadata.
>>
>> In another words.... there should be no 000_config.sql, the option
>> table should be empty as long as the user does not modify any of
>> the
>> options.
>>
>
> Lets assume that we are going for it, how would you upgrade from the
> current state to your suggested solution keeping all user current
> settings ?
Either by:
1. leaving all existing data within database... so current users will not enjoy updating
defaults in future. I really don't like this solution, but it will work.
2. during upgrade, go over the values, and remove all that matches the metadata default.
This way, future change in metadata will apply.
>
>>> b)There may be other requirements on configuration that are
>>> easier
>>> to
>>> manage in the database, for example, I have heard that one of the
>>> suggested features regarding configuration is to keep a kind of
>>> configuration history and know exactly which configuration values
>>> was changed, when and by whom.
>>
>> There is no conflict. You can have audit table when modifying
>> options.
>> Keep in mind that I discuss the option metadata.
>> I believe you are discussing the option data.
> You are right
>
>>
>>> c) The version mechanism in the config is working like this :
>>> there
>>> is a 'general' version , means that this value is not version
>>> dependant, or the version can be a real version like 3.1 3.2 etc
>>> ,
>>> in such case the value is version dependant and an entry is
>>> required
>>> for each version.
>>
>> Again, there is no conflict, as the default value within the
>> metadata
>> can be version specific too.
> I agree , however we should consider all changes in current code +
> tools + upgrade since this seems a major change
Right. I outlined all changes I collected in the initial message.
>>
>> Having said that, I don't understand how two different versions can
>> work with the different data models and share one database and
>> options.
>>
>>> I agree however, that the default value in the code is redundant
>>> and
>>> error prone and should be removed.
>>
>> From what you wrote above, I don't understand how you reached to
>> this
>> conclusion. Can you please explain?
> I mean that we have now defaults in code (ConfigValues.java) and in
> the database they may not match.
> I think as you that only one place defined the defaults, so , it
> should be removed from code which is less flexible if we want to
> change something without recompiling ...
If we decide to use java annotations for metadata, the default will be in annotation.
If we decide to use XML for metadata, the default will be in XML.
At any case, I would like to reach to a state where the metadata is at one place, and not
spread between code, property/xml, database.
I may be missing something.
are you suggesting moving all the vdc_options table to an xml file?
I assume it will be placed under /etc?
then if we update the rpm, the edited config will remain unmodified, and
we'll get the new one as rpmsave (iirc).
then during upgrade process we'll need to merge these files?
5:57 p.m.
On 09/13/2012 05:50 PM, Itamar Heim wrote:
On 09/13/2012 11:36 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Eli Mesika" <emesika(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
>> Sent: Thursday, September 13, 2012 10:46:41 AM
>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
>> options
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> To: "Eli Mesika" <emesika(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
>>> Sent: Wednesday, September 12, 2012 3:57:13 PM
>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default
>>> options
>>>
>>>
>>> Hello Eli,
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika(a)redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer"
<lpeer(a)redhat.com>
>>>> Sent: Wednesday, September 12, 2012 3:48:00 PM
>>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>>> default
>>>> options
>>>>
>>>>>>>>> QUESTIONS
>>>>>>>>>
>>>>>>>>> 1. Why do we store default values in database?
>>>>
>>>> I wanted to add few important points
>>>> a) We have default values in DB in order to enable overriding
>>>> values
>>>> in the 0000_config.sql file only if a customer did not change the
>>>> default value, if a customer changed the default in some entries,
>>>> we
>>>> want to honour the customer settings
>>>
>>> Default != value.
>>> Default is what should be used if not specified explicitly
I agree
here, maybe we should consider a future possibility of "reset to
default value"
>>>
>>> Current implementation puts the default value as a value, so you
>>> cannot distinguish between what user enforced.
>>>
>>> When a default is changed, because of field feedback, we should
>>> push
>>> this into the database instead of keeping in database only options
>>> that were modified by the user and fetch the default from the
>>> option
>>> metadata.
>>>
>>> In another words.... there should be no 000_config.sql, the option
>>> table should be empty as long as the user does not modify any of
>>> the
>>> options.
Not sure I fully understand how upgrade of configuration will look?
I'm talking about update of existing data (+meta data - for example,
change of existing description) vs introducing of new data (+ metadata)
>>>
>>
>> Lets assume that we are going for it, how would you upgrade from the
>> current state to your suggested solution keeping all user current
>> settings ?
>
> Either by:
>
> 1. leaving all existing data within database... so current users will
> not enjoy updating defaults in future. I really don't like this
> solution, but it will work.
>
> 2. during upgrade, go over the values, and remove all that matches the
> metadata default. This way, future change in metadata will apply.
>
>>
>>>> b)There may be other requirements on configuration that are
>>>> easier
>>>> to
>>>> manage in the database, for example, I have heard that one of the
>>>> suggested features regarding configuration is to keep a kind of
>>>> configuration history and know exactly which configuration values
>>>> was changed, when and by whom.
>>>
>>> There is no conflict. You can have audit table when modifying
>>> options.
>>> Keep in mind that I discuss the option metadata.
>>> I believe you are discussing the option data.
>> You are right
>>
>>>
>>>> c) The version mechanism in the config is working like this :
>>>> there
>>>> is a 'general' version , means that this value is not version
>>>> dependant, or the version can be a real version like 3.1 3.2 etc
>>>> ,
>>>> in such case the value is version dependant and an entry is
>>>> required
>>>> for each version.
>>>
>>> Again, there is no conflict, as the default value within the
>>> metadata
>>> can be version specific too.
>> I agree , however we should consider all changes in current code +
>> tools + upgrade since this seems a major change
>
> Right. I outlined all changes I collected in the initial message.
>
>>>
>>> Having said that, I don't understand how two different versions can
>>> work with the different data models and share one database and
>>> options.
>>>
>>>> I agree however, that the default value in the code is redundant
>>>> and
>>>> error prone and should be removed.
>>>
>>> From what you wrote above, I don't understand how you reached to
>>> this
>>> conclusion. Can you please explain?
>> I mean that we have now defaults in code (ConfigValues.java) and in
>> the database they may not match.
>> I think as you that only one place defined the defaults, so , it
>> should be removed from code which is less flexible if we want to
>> change something without recompiling ...
>
> If we decide to use java annotations for metadata, the default will be
> in annotation.
> If we decide to use XML for metadata, the default will be in XML.
> At any case, I would like to reach to a state where the metadata is at
> one place, and not spread between code, property/xml, database.
I may be missing something.
are you suggesting moving all the vdc_options table to an xml file?
I assume it will be placed under /etc?
then if we update the rpm, the edited config will remain unmodified, and
we'll get the new one as rpmsave (iirc).
then during upgrade process we'll need to merge these files?
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:27 p.m.
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Thursday, September 13, 2012 5:57:48 PM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
On 09/13/2012 05:50 PM, Itamar Heim wrote:
> On 09/13/2012 11:36 AM, Alon Bar-Lev wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Eli Mesika" <emesika(a)redhat.com>
>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer"
<lpeer(a)redhat.com>
>>> Sent: Thursday, September 13, 2012 10:46:41 AM
>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>> default
>>> options
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>> To: "Eli Mesika" <emesika(a)redhat.com>
>>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer"
<lpeer(a)redhat.com>
>>>> Sent: Wednesday, September 12, 2012 3:57:13 PM
>>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>>> default
>>>> options
>>>>
>>>>
>>>> Hello Eli,
>>>>
>>>> ----- Original Message -----
>>>>> From: "Eli Mesika" <emesika(a)redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer"
<lpeer(a)redhat.com>
>>>>> Sent: Wednesday, September 12, 2012 3:48:00 PM
>>>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>>>> default
>>>>> options
>>>>>
>>>>>>>>>> QUESTIONS
>>>>>>>>>>
>>>>>>>>>> 1. Why do we store default values in database?
>>>>>
>>>>> I wanted to add few important points
>>>>> a) We have default values in DB in order to enable overriding
>>>>> values
>>>>> in the 0000_config.sql file only if a customer did not change
>>>>> the
>>>>> default value, if a customer changed the default in some
>>>>> entries,
>>>>> we
>>>>> want to honour the customer settings
>>>>
>>>> Default != value.
>>>> Default is what should be used if not specified explicitly
I agree here, maybe we should consider a future possibility of "reset
to
default value"
Right, will be implemented.
>>>>
>>>> Current implementation puts the default value as a value, so you
>>>> cannot distinguish between what user enforced.
>>>>
>>>> When a default is changed, because of field feedback, we should
>>>> push
>>>> this into the database instead of keeping in database only
>>>> options
>>>> that were modified by the user and fetch the default from the
>>>> option
>>>> metadata.
>>>>
>>>> In another words.... there should be no 000_config.sql, the
>>>> option
>>>> table should be empty as long as the user does not modify any of
>>>> the
>>>> options.
Not sure I fully understand how upgrade of configuration will look?
I'm talking about update of existing data (+meta data - for example,
change of existing description) vs introducing of new data (+
metadata)
Metadata is not updated. it is delivered with release.
It comes as resource as any other resource we have within application.
Adding a new option to metadata implies that this option was not available at previous
release, so after upgrade if application tries to access this option it will not find it
in database and then retrieve the default from the metadata.
If a description is updated within metadata, it will be available immediately after
upgrade, as description is taken directly from metadata.
I may miss something from your question...
>>>>
>>>
>>> Lets assume that we are going for it, how would you upgrade from
>>> the
>>> current state to your suggested solution keeping all user current
>>> settings ?
>>
>> Either by:
>>
>> 1. leaving all existing data within database... so current users
>> will
>> not enjoy updating defaults in future. I really don't like this
>> solution, but it will work.
>>
>> 2. during upgrade, go over the values, and remove all that matches
>> the
>> metadata default. This way, future change in metadata will apply.
>>
>>>
>>>>> b)There may be other requirements on configuration that are
>>>>> easier
>>>>> to
>>>>> manage in the database, for example, I have heard that one of
>>>>> the
>>>>> suggested features regarding configuration is to keep a kind of
>>>>> configuration history and know exactly which configuration
>>>>> values
>>>>> was changed, when and by whom.
>>>>
>>>> There is no conflict. You can have audit table when modifying
>>>> options.
>>>> Keep in mind that I discuss the option metadata.
>>>> I believe you are discussing the option data.
>>> You are right
>>>
>>>>
>>>>> c) The version mechanism in the config is working like this :
>>>>> there
>>>>> is a 'general' version , means that this value is not
version
>>>>> dependant, or the version can be a real version like 3.1 3.2
>>>>> etc
>>>>> ,
>>>>> in such case the value is version dependant and an entry is
>>>>> required
>>>>> for each version.
>>>>
>>>> Again, there is no conflict, as the default value within the
>>>> metadata
>>>> can be version specific too.
>>> I agree , however we should consider all changes in current code
>>> +
>>> tools + upgrade since this seems a major change
>>
>> Right. I outlined all changes I collected in the initial message.
>>
>>>>
>>>> Having said that, I don't understand how two different versions
>>>> can
>>>> work with the different data models and share one database and
>>>> options.
>>>>
>>>>> I agree however, that the default value in the code is
>>>>> redundant
>>>>> and
>>>>> error prone and should be removed.
>>>>
>>>> From what you wrote above, I don't understand how you reached
>>>> to
>>>> this
>>>> conclusion. Can you please explain?
>>> I mean that we have now defaults in code (ConfigValues.java) and
>>> in
>>> the database they may not match.
>>> I think as you that only one place defined the defaults, so , it
>>> should be removed from code which is less flexible if we want to
>>> change something without recompiling ...
>>
>> If we decide to use java annotations for metadata, the default
>> will be
>> in annotation.
>> If we decide to use XML for metadata, the default will be in XML.
>> At any case, I would like to reach to a state where the metadata
>> is at
>> one place, and not spread between code, property/xml, database.
>
> I may be missing something.
> are you suggesting moving all the vdc_options table to an xml file?
> I assume it will be placed under /etc?
>
> then if we update the rpm, the edited config will remain
> unmodified, and
> we'll get the new one as rpmsave (iirc).
> then during upgrade process we'll need to merge these files?
> _______________________________________________
> 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
9:23 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Eli Mesika" <emesika(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, September 13, 2012 5:50:06 PM
Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
On 09/13/2012 11:36 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Eli Mesika" <emesika(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com>
>> Sent: Thursday, September 13, 2012 10:46:41 AM
>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>> default options
>>
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> To: "Eli Mesika" <emesika(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer"
<lpeer(a)redhat.com>
>>> Sent: Wednesday, September 12, 2012 3:57:13 PM
>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>> default
>>> options
>>>
>>>
>>> Hello Eli,
>>>
>>> ----- Original Message -----
>>>> From: "Eli Mesika" <emesika(a)redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>> Cc: engine-devel(a)ovirt.org, "Livnat Peer"
<lpeer(a)redhat.com>
>>>> Sent: Wednesday, September 12, 2012 3:48:00 PM
>>>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config
>>>> default
>>>> options
>>>>
>>>>>>>>> QUESTIONS
>>>>>>>>>
>>>>>>>>> 1. Why do we store default values in database?
>>>>
>>>> I wanted to add few important points
>>>> a) We have default values in DB in order to enable overriding
>>>> values
>>>> in the 0000_config.sql file only if a customer did not change
>>>> the
>>>> default value, if a customer changed the default in some
>>>> entries,
>>>> we
>>>> want to honour the customer settings
>>>
>>> Default != value.
>>> Default is what should be used if not specified explicitly
>>>
>>> Current implementation puts the default value as a value, so you
>>> cannot distinguish between what user enforced.
>>>
>>> When a default is changed, because of field feedback, we should
>>> push
>>> this into the database instead of keeping in database only
>>> options
>>> that were modified by the user and fetch the default from the
>>> option
>>> metadata.
>>>
>>> In another words.... there should be no 000_config.sql, the
>>> option
>>> table should be empty as long as the user does not modify any of
>>> the
>>> options.
>>>
>>
>> Lets assume that we are going for it, how would you upgrade from
>> the
>> current state to your suggested solution keeping all user current
>> settings ?
>
> Either by:
>
> 1. leaving all existing data within database... so current users
> will not enjoy updating defaults in future. I really don't like
> this solution, but it will work.
>
> 2. during upgrade, go over the values, and remove all that matches
> the metadata default. This way, future change in metadata will
> apply.
>
>>
>>>> b)There may be other requirements on configuration that are
>>>> easier
>>>> to
>>>> manage in the database, for example, I have heard that one of
>>>> the
>>>> suggested features regarding configuration is to keep a kind of
>>>> configuration history and know exactly which configuration
>>>> values
>>>> was changed, when and by whom.
>>>
>>> There is no conflict. You can have audit table when modifying
>>> options.
>>> Keep in mind that I discuss the option metadata.
>>> I believe you are discussing the option data.
>> You are right
>>
>>>
>>>> c) The version mechanism in the config is working like this :
>>>> there
>>>> is a 'general' version , means that this value is not version
>>>> dependant, or the version can be a real version like 3.1 3.2 etc
>>>> ,
>>>> in such case the value is version dependant and an entry is
>>>> required
>>>> for each version.
>>>
>>> Again, there is no conflict, as the default value within the
>>> metadata
>>> can be version specific too.
>> I agree , however we should consider all changes in current code +
>> tools + upgrade since this seems a major change
>
> Right. I outlined all changes I collected in the initial message.
>
>>>
>>> Having said that, I don't understand how two different versions
>>> can
>>> work with the different data models and share one database and
>>> options.
>>>
>>>> I agree however, that the default value in the code is redundant
>>>> and
>>>> error prone and should be removed.
>>>
>>> From what you wrote above, I don't understand how you reached to
>>> this
>>> conclusion. Can you please explain?
>> I mean that we have now defaults in code (ConfigValues.java) and
>> in
>> the database they may not match.
>> I think as you that only one place defined the defaults, so , it
>> should be removed from code which is less flexible if we want to
>> change something without recompiling ...
>
> If we decide to use java annotations for metadata, the default will
> be in annotation.
> If we decide to use XML for metadata, the default will be in XML.
> At any case, I would like to reach to a state where the metadata is
> at one place, and not spread between code, property/xml, database.
I may be missing something.
are you suggesting moving all the vdc_options table to an xml file?
I assume it will be placed under /etc?
then if we update the rpm, the edited config will remain unmodified,
and
we'll get the new one as rpmsave (iirc).
then during upgrade process we'll need to merge these files?
No... the vdc_options stays exactly as-is.
I am suggesting to move the metadata to one place.
metadata = option name, description, reloadable, password, default value, restriction.
metadata is part of release, and not changed by user.
Alon.
4449
days inactive
4453
days old
21 comments
5 participants
participants (5)
-
Alon Bar-Lev -
Eli Mesika -
Itamar Heim -
Livnat Peer -
Yair Zaslavsky