[Engine-devel] Reloadable Configuration - Wiki Page
Hi All, Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment. http://www.ovirt.org/wiki/Features/ReloadableConfiguration Thanks, Muli
1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk. 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon. 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call. something in the form of: WARNING option XXXXX changed a reboot is required for it to take affect. 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for. These are things I'm not against I just want more explanation about: 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration. 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value. ----- Original Message -----
From: "Muli Salem" <msalem@redhat.com> To: engine-devel@ovirt.org Sent: Monday, March 26, 2012 1:10:10 PM Subject: [Engine-devel] Reloadable Configuration - Wiki Page
Hi All,
Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment.
http://www.ovirt.org/wiki/Features/ReloadableConfiguration
Thanks, Muli _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 03/26/2012 09:53 PM, Saggi Mizrahi wrote:
1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk. 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon. 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call. something in the form of: WARNING option XXXXX changed a reboot is required for it to take affect. 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.
a different take on this - why not just annotate the enums with this information? also, not sure configuration should be reloaded per change automatically. maybe user wants it to happen on next restart, maybe some changes must happen together. i.e., I'd expect a specific 'reconfigure' call to make it happen rather than poll for it.
These are things I'm not against I just want more explanation about: 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration. 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value.
----- Original Message -----
From: "Muli Salem"<msalem@redhat.com> To: engine-devel@ovirt.org Sent: Monday, March 26, 2012 1:10:10 PM Subject: [Engine-devel] Reloadable Configuration - Wiki Page
Hi All,
Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment.
http://www.ovirt.org/wiki/Features/ReloadableConfiguration
Thanks, Muli _______________________________________________ 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 03/27/2012 08:18 AM, Itamar Heim wrote:
On 03/26/2012 09:53 PM, Saggi Mizrahi wrote:
1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk. 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon. 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call. something in the form of: WARNING option XXXXX changed a reboot is required for it to take affect. 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already
Agreed. Current code in engine-core uses a generic method to get the value, and uses @TypeConverterAttribute annotation to give indication to which type the data should be "cast" to. See DbConfigUtils.parseValue(String value, String name, java.lang.Class<?> fieldType)
written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.
a different take on this - why not just annotate the enums with this information?
+1 On annotation idea - although this introduces "information on behavior" to code, and any change will require re-compiling, I don't see why anyone would like to change the behavior.
also, not sure configuration should be reloaded per change automatically. maybe user wants it to happen on next restart, maybe some changes must happen together. i.e., I'd expect a specific 'reconfigure' call to make it happen rather than poll for it.
These are things I'm not against I just want more explanation about: 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration. 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value. Muli - are you sure about Quartz? Have you checked it out?
----- Original Message -----
From: "Muli Salem"<msalem@redhat.com> To: engine-devel@ovirt.org Sent: Monday, March 26, 2012 1:10:10 PM Subject: [Engine-devel] Reloadable Configuration - Wiki Page
Hi All,
Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment.
http://www.ovirt.org/wiki/Features/ReloadableConfiguration
Thanks, Muli _______________________________________________ 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
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration 1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes. ----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, March 27, 2012 1:20:01 PM Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
On 03/27/2012 08:18 AM, Itamar Heim wrote:
On 03/26/2012 09:53 PM, Saggi Mizrahi wrote:
1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk. 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon. 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call. something in the form of: WARNING option XXXXX changed a reboot is required for it to take affect. 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already
Agreed. Current code in engine-core uses a generic method to get the value, and uses @TypeConverterAttribute annotation to give indication to which type the data should be "cast" to. See DbConfigUtils.parseValue(String value, String name, java.lang.Class<?> fieldType)
written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.
a different take on this - why not just annotate the enums with this information?
+1 On annotation idea - although this introduces "information on behavior" to code, and any change will require re-compiling, I don't see why anyone would like to change the behavior.
also, not sure configuration should be reloaded per change automatically. maybe user wants it to happen on next restart, maybe some changes must happen together. i.e., I'd expect a specific 'reconfigure' call to make it happen rather than poll for it.
These are things I'm not against I just want more explanation about: 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration. 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value. Muli - are you sure about Quartz? Have you checked it out?
----- Original Message -----
From: "Muli Salem"<msalem@redhat.com> To: engine-devel@ovirt.org Sent: Monday, March 26, 2012 1:10:10 PM Subject: [Engine-devel] Reloadable Configuration - Wiki Page
Hi All,
Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment.
http://www.ovirt.org/wiki/Features/ReloadableConfiguration
Thanks, Muli _______________________________________________ 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
_______________________________________________ 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 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run... We can get it in 2 options: 1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials. Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb. I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-). A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially. /d
On 03/29/2012 11:59 AM, Doron Fediuck wrote:
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run...
We can get it in 2 options:
1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials.
Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb.
I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-).
true.
A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially.
/d
isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must) other options: 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible 2. use a way on the host to send a signal (change a file, process signal, etc.)
On 29/03/12 12:13, Itamar Heim wrote:
On 03/29/2012 11:59 AM, Doron Fediuck wrote:
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run...
We can get it in 2 options:
1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials.
Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb.
I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-).
true.
A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially.
Any thoughts on this?
/d
isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
other options: 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple
Simply signaling a process such as "kill TRAP PID" is problematic since: - The engine core is a web-app on top of JBoss, how do we know which pid to trigger? - What happens if JBoss isn't running / using nohup / ... ? script (embedded or not in the config utility).
2. use a way on the host to send a signal (change a file, process signal, etc.) Great. This means we need to poll a folder or similar (DB)... sounds familiar? See above the periodic reload. We can do it better if we look for a key in the DB (enableReconfigure=true), to avoid reloading in the middle of an update process of several keys. We still need to be careful from concurrency, but I have solutions for this as well (do not allow updates to vdc_options until the key becomes false again, also set it to false on initial boot).
3. Write a simple public reload servlet (maybe limit to local host only?), which we can call using simple curl http://xxx/reload? As I see it now, I'd go for one of the following (in this order)- 2: periodically poll DB, reload only when allowed. 3: local servlet. Thoughts? Better solutions?
I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :). The whole debate about permissions is a causing my spidy sense to tingle. My main question is, What are the options you actually want to make as engine configuration? At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes. To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object. The interval in which to check for storage liveness is a data center setting, not an Engine setting as well. In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities. Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around. ----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, March 29, 2012 8:42:05 AM Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
On 29/03/12 12:13, Itamar Heim wrote:
On 03/29/2012 11:59 AM, Doron Fediuck wrote:
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run...
We can get it in 2 options:
1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials.
Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb.
I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-).
true.
A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially.
Any thoughts on this?
/d
isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
Simply signaling a process such as "kill TRAP PID" is problematic since: - The engine core is a web-app on top of JBoss, how do we know which pid to trigger? - What happens if JBoss isn't running / using nohup / ... ?
other options: 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple script (embedded or not in the config utility).
2. use a way on the host to send a signal (change a file, process signal, etc.) Great. This means we need to poll a folder or similar (DB)... sounds familiar? See above the periodic reload. We can do it better if we look for a key in the DB (enableReconfigure=true), to avoid reloading in the middle of an update process of several keys. We still need to be careful from concurrency, but I have solutions for this as well (do not allow updates to vdc_options until the key becomes false again, also set it to false on initial boot).
3. Write a simple public reload servlet (maybe limit to local host only?), which we can call using simple curl http://xxx/reload?
As I see it now, I'd go for one of the following (in this order)- 2: periodically poll DB, reload only when allowed. 3: local servlet.
Thoughts? Better solutions? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Indeed you're taking it sideways. We have a concept we can improve, and this can be done in 2 ways; 1. Stop the press, break current implementation and re-write it to support instances. 2. Handle reload to help current users, and set (1) as an RFE for 3.2. I'm not sure how long the engine can wait to stabilize after (1) or several iterations of it. So gradually working toward it (such as 2 suggests) may be more user friendly. Does it makes sense? On 31/03/12 00:50, Saggi Mizrahi wrote:
I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :). The whole debate about permissions is a causing my spidy sense to tingle.
My main question is, What are the options you actually want to make as engine configuration? At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes.
To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object. The interval in which to check for storage liveness is a data center setting, not an Engine setting as well.
In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities.
Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around.
----- Original Message -----
From: "Doron Fediuck" <dfediuck@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, March 29, 2012 8:42:05 AM Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
On 29/03/12 12:13, Itamar Heim wrote:
On 03/29/2012 11:59 AM, Doron Fediuck wrote:
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run...
We can get it in 2 options:
1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials.
Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb.
I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-).
true.
A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially.
Any thoughts on this?
/d
isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
Simply signaling a process such as "kill TRAP PID" is problematic since: - The engine core is a web-app on top of JBoss, how do we know which pid to trigger? - What happens if JBoss isn't running / using nohup / ... ?
other options: 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple script (embedded or not in the config utility).
2. use a way on the host to send a signal (change a file, process signal, etc.) Great. This means we need to poll a folder or similar (DB)... sounds familiar? See above the periodic reload. We can do it better if we look for a key in the DB (enableReconfigure=true), to avoid reloading in the middle of an update process of several keys. We still need to be careful from concurrency, but I have solutions for this as well (do not allow updates to vdc_options until the key becomes false again, also set it to false on initial boot).
3. Write a simple public reload servlet (maybe limit to local host only?), which we can call using simple curl http://xxx/reload?
As I see it now, I'd go for one of the following (in this order)- 2: periodically poll DB, reload only when allowed. 3: local servlet.
Thoughts? Better solutions? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 03/31/2012 12:50 AM, Saggi Mizrahi wrote:
I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :). The whole debate about permissions is a causing my spidy sense to tingle.
My main question is, What are the options you actually want to make as engine configuration? At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes.
I don't think we should start by making every config variable at instance level. the config table allows system level defaults, which are easy to handle/manage. where there is sufficient need to create an instance level tweak, it is usually done with due consideration to making it a feature, which is usually a lengthier process.
To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object. The interval in which to check for storage liveness is a data center setting, not an Engine setting as well.
true, but apparently so far there wasn't a need to tweak it at DC or cluster level, and engine level was good enough. best is sometimes enemy of good. and adding a lot of configurable options at entity level doesn't necessarily make things simpler for admins to understand. so i agree some options should be at instance level, but only when there is a good enough reason to do so.
In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities.
Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around.
----- Original Message -----
From: "Doron Fediuck"<dfediuck@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, March 29, 2012 8:42:05 AM Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
On 29/03/12 12:13, Itamar Heim wrote:
On 03/29/2012 11:59 AM, Doron Fediuck wrote:
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote:
Thanks for the comments, I updated the wiki page accordingly: http://www.ovirt.org/wiki/Features/ReloadableConfiguration
1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues. 2. Found a way to update the Quartz jobs, at least basic issues such as interval size. 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run...
We can get it in 2 options:
1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials.
Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb.
I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-).
true.
A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially.
Any thoughts on this?
/d
isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
Simply signaling a process such as "kill TRAP PID" is problematic since: - The engine core is a web-app on top of JBoss, how do we know which pid to trigger? - What happens if JBoss isn't running / using nohup / ... ?
other options: 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple script (embedded or not in the config utility).
2. use a way on the host to send a signal (change a file, process signal, etc.) Great. This means we need to poll a folder or similar (DB)... sounds familiar? See above the periodic reload. We can do it better if we look for a key in the DB (enableReconfigure=true), to avoid reloading in the middle of an update process of several keys. We still need to be careful from concurrency, but I have solutions for this as well (do not allow updates to vdc_options until the key becomes false again, also set it to false on initial boot).
3. Write a simple public reload servlet (maybe limit to local host only?), which we can call using simple curl http://xxx/reload?
As I see it now, I'd go for one of the following (in this order)- 2: periodically poll DB, reload only when allowed. 3: local servlet.
Thoughts? Better solutions? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
I'll try and sum up while rebutting as I get confused when mail threads become to long. Your points as I understand them: 1. Moving the configuration to the instance level instead of system level is harder to implement. [A] You are right when you talk about existing codebase, the question is will future configuration be written directly as instance configuration or will we continue abusing the system configuration until it's integrated in. 2. Using the config for system level defaults. [A] Defaults are values that we as developers recommend for options. Letting the user change the defaults is actually letting the user set the value. If you are talking about configuration having a configuration hierarchy. Engine is not a parent objects to pin the hierarchy to as it's not an actual actor in the BL. 3. No need to set until there is an instance level tweak is required. [A] If you set up the configuration hierarchy properly you could have the attribute getters recognize this hierarchy and only have a setter (and the proper db scheme) written when instance level tweaking is required. This way you remove the complexity but keep object relation correctness. My opinion is usually that doing things properly might look like a lot of work now but in the long run you save more time. Further more, you can hide the fact that you are doing things wrong when you lack the time to actually do things properly. VDSM for instance hides global configuration accesses in instance getters and constructors. So even though the configuration is in the wrong place it is modeled in correctly and as we slowly move things the rest of the code isn't (for the most part) doing things like accessing objects configuration directly and other such atrocities. In more practical terms, you could have settings per class\service instead of per instance and later you can actually use this as the basis for a configuration hierarchy. IMO This will be easier to model into the current authentication model, and integrate in. Always remember that one of the pillars of OOP is encapsulation, so even if you decide to keep all the values in one table, it will be smart to still define who owns what values in code instead of having a ConfigurationManager singleton and have everyone access it directly. But again, I'm not as versed in the Engine code as you all are and this might be more complicated than it looks to an outsider. In broader strokes, my personal preference is to have an idea of how you want the configuration to work *ideally* and then start to take concessions due to resource limitations. Instead of just deciding to hack something in and worry about things later. ----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com> Cc: "Doron Fediuck" <dfediuck@redhat.com>, engine-devel@ovirt.org Sent: Sunday, April 1, 2012 7:12:51 PM Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
On 03/31/2012 12:50 AM, Saggi Mizrahi wrote:
I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :). The whole debate about permissions is a causing my spidy sense to tingle.
My main question is, What are the options you actually want to make as engine configuration? At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes.
I don't think we should start by making every config variable at instance level. the config table allows system level defaults, which are easy to handle/manage. where there is sufficient need to create an instance level tweak, it is usually done with due consideration to making it a feature, which is usually a lengthier process.
To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object. The interval in which to check for storage liveness is a data center setting, not an Engine setting as well.
true, but apparently so far there wasn't a need to tweak it at DC or cluster level, and engine level was good enough. best is sometimes enemy of good. and adding a lot of configurable options at entity level doesn't necessarily make things simpler for admins to understand.
so i agree some options should be at instance level, but only when there is a good enough reason to do so.
In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities.
Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around.
----- Original Message -----
From: "Doron Fediuck"<dfediuck@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, March 29, 2012 8:42:05 AM Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
On 29/03/12 12:13, Itamar Heim wrote:
On 03/29/2012 11:59 AM, Doron Fediuck wrote:
On 29/03/12 10:54, Itamar Heim wrote:
On 03/29/2012 10:05 AM, Muli Salem wrote: > Thanks for the comments, I updated the wiki page accordingly: > http://www.ovirt.org/wiki/Features/ReloadableConfiguration > > 1. Instead of the new DB column is_reloadable --> > Annotation > to ConfigValues. > 2. Found a way to update the Quartz jobs, at least basic > issues > such as interval size. > 3. The values will be reloaded upon admin's decision to do so > - > with a new command in the engine-config CLI, since that is > where admins make the changes.
just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
Basically we need a script using the REST sdk to trigger re-configuration This script will need the engine's IP so it'll know where to find it. The thing is, REST also needs the admin's user and password to run...
We can get it in 2 options:
1. Store Admin's user+pass in the engine's conf file. 2. Use engine-config to fetch the credentials.
Once we have credentials, we can use it with a new script to trigger configuration reload. We can also incorporate this script into engine-config so admin won't need to know another script, and simply use a 'reload' verb.
I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't be a first time. Any better alternative is welcome (just as patches ;-).
true.
A simple alternative to the whole credentials and IP need, is a simple periodic reload, as suggested initially.
Any thoughts on this?
/d
isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
Simply signaling a process such as "kill TRAP PID" is problematic since: - The engine core is a web-app on top of JBoss, how do we know which pid to trigger? - What happens if JBoss isn't running / using nohup / ... ?
other options: 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple script (embedded or not in the config utility).
2. use a way on the host to send a signal (change a file, process signal, etc.) Great. This means we need to poll a folder or similar (DB)... sounds familiar? See above the periodic reload. We can do it better if we look for a key in the DB (enableReconfigure=true), to avoid reloading in the middle of an update process of several keys. We still need to be careful from concurrency, but I have solutions for this as well (do not allow updates to vdc_options until the key becomes false again, also set it to false on initial boot).
3. Write a simple public reload servlet (maybe limit to local host only?), which we can call using simple curl http://xxx/reload?
As I see it now, I'd go for one of the following (in this order)- 2: periodically poll DB, reload only when allowed. 3: local servlet.
Thoughts? Better solutions? _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 26/03/12 21:53, Saggi Mizrahi wrote:
1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk.
I agree, I think this should not be persist in the data base, a simple annotation can do the work of marking a property as re-loadable or not.
2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon.
+1, I think reloading configuration values should be only on demand.
3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call. something in the form of: WARNING option XXXXX changed a reboot is required for it to take affect.
A nice to have IMO, we don't have it today and all values change require reboot.
4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.
I think it is used for validations but I don't really remember I can take a look.
These are things I'm not against I just want more explanation about: 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it.
What do you mean by committed to it? the DB schema is not part of the API, we change it as we go.
same as having a property file and changing the key in it (only the upgrade process is much easier when you are using data base). Having a regular config file might be simpler for users to edit and for you to maintain.
not sure what you mean by 'regular', in the enterprise management world storing configuration in data base is a regular thing to do.
The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration.
And the tools you have for data bases which make the maintaining process much easier.
2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value.
The definition of what is reloadable is based on how much work it takes to change it from a static config to a reloadable config. Of course you can reload the time configuration used by a quartz service it requires to cancel the job and reschedule it with the new configuration value. it is just not as easy as the other changes that's why this is the 4th phase of this feature.
----- Original Message -----
From: "Muli Salem" <msalem@redhat.com> To: engine-devel@ovirt.org Sent: Monday, March 26, 2012 1:10:10 PM Subject: [Engine-devel] Reloadable Configuration - Wiki Page
Hi All,
Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment.
http://www.ovirt.org/wiki/Features/ReloadableConfiguration
Thanks, Muli _______________________________________________ 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
participants (6)
-
Doron Fediuck -
Itamar Heim -
Livnat Peer -
Muli Salem -
Saggi Mizrahi -
Yair Zaslavsky