[Engine-devel] [RFC] ovirt-engine - vdc_config default options
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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...
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.
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....
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, engine-devel@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.
On 10/09/12 09:30, Alon Bar-Lev wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, engine-devel@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.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 10/09/12 11:30, Alon Bar-Lev wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@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
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Hello Eli, ----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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.
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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
On 09/13/2012 11:36 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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?
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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Eli Mesika" <emesika@redhat.com>, engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Eli Mesika" <emesika@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org, "Livnat Peer" <lpeer@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.
participants (5)
-
Alon Bar-Lev -
Eli Mesika -
Itamar Heim -
Livnat Peer -
Yair Zaslavsky