Examples of properties that should be moved: # Email rhq.server.email.smtp-host=localhost rhq.server.email.smtp-port=25 rhq.server.email.from-address=rhqadmin@localhost # Operations/controls timeout # Defines the default timeout for all operations (specified in seconds) rhq.server.operation-timeout=600
This may or may not be true and it depends on the property. Keep in mind the future requirement of being able to cluster the server. There may be cases where certain properties must be set on a per-server basis (i.e. rhq-server.properties). Putting things in the database in RHQ_SYSTEM_CONFIG means ALL servers in the cluster will have the identical settings. This may not be want you want (e.g. the email SMTP host/port may be different depending on where in the network particular RHQ Server nodes are deployed).
Moving to future
will use this jira to keep track of what could possible be reset via the server admin page in an HA environment.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-146
joseph, current thoughts?
I think ALL entries in the rhq-server.properties file should be editable through the UI. However, instead of editing them one at a time, we should use the group configuration component to render the UI. In this way, the administrator can easily choose which properties should have the same value across the server cluster, and which should have different values - the group config component allows both of these use cases easily. The only question we have is whether we build this functionality into the core UI, or develop it as the configuration subsystem implementation for the RHQ Server resource type. The former has the benefit of being configurable regardless of whether the RHQ Server(s) have been discovered/imported, and can also be made available through the admin pages. The latter might/should be an easier solution implementation-wise, because it fits into our existing plugin model.