RHQ has an extremely powerful configuration subsystem. RHQ will provide a view into a resource's live configuration, maintain a history of configuration revisions and allow the user to view or rollback to previous revisions. This page will describe in how to use the configuration subsystem in RHQ.
The following are concepts that relate to the configuration subsystem.
As with most subsystems, some but not all resources will support editing their configuration remotely via RHQ. For example, a Postgres Server's postgresql.conf file or a JBossAS4 Datasource's ds.xml file can be viewed or edited using RHQ. When you're looking at a single resource, you'll see various tabs in the main content area. The 'Configuration' tab will only be display for resources that support remote configuration:
- You can retrieve the current configuration of a resource.
- You can apply configuration changes to a resource, keeping an audit trail of changes.
- You can apply changes to a group of resources simultaneously, keeping fine-grained audit trail of changes.
- You can have alerts fired if external changes to configuration is detected.
- You can rollback to a previous configuration.
When you navigate to a resource's Configuration>Current tab in the web console, you will be shown the current configuration of that resource. If the resource is currently up, this will actually be the live configuration of that resource.
Changes to the configuration of a resource work differently under the covers depending on which type of resource is being configured. Updating a configuration may mean calling out to an exposed API on the managed resource (such as SNMP or JMX), editing a simple name-value pair file on disk, or even interacting with another service which knows how to reconfigure the target resource (such as Augeas). But regardless of the particular method that the agent must use to retrieve and change configuration, the general steps always remain the same within RHQ's user interface.
- The user views the current configuration of the resource using the RHQ web console.
- The user can choose to add, remove, or edit one or many properties under that configuration.
- RHQ performs all necessary validation of the updated configuration, errors are displayed in the web console which the user must fix before the new values will be persisted.
- Once validation succeeds, RHQ records a copy of this action (an audit trail of configuration change requests) and asynchronously sends the new values down to the agent managing the specific resource.
- The agent applies the configuration changes on behalf of the requesting user, and reports success or failure.
- The server updates the audit trail record with the successful or failed status.
Before allowing any configuration changes to be submitted, RHQ will validate each and every property. Required properties must have a non-empty value, whereas "null" or "unset" values are allowed for optional properties. For an unset optional property, the underlying managed resource will use its own internal default value.
It is possible to perform a bulk configuration change across a group of resources. See Group Configuration for more information.
The configuration history page will show you an audit trail of past configuration change attempts. You can see which configuration changes were successful, which failed and which are currently in progress.
You can compare two or more configuration changes from the history view to find out the differences between them. This allows you to more easily determine what changed between configurations.
Should you determine that a resource's current configuration is not what you want, you have the option to rollback to a previous configuration. Simple select the configuration from the list in the history page and press the Rollback button.
Since version 2.2, RHQ has the ability to detect when configuration changes have been made externally. These changes are captured in the audit trail, which gives users the ability to revert any unwanted changes by rolling back to a previous version of the configuration. Best of all, you can create alert definitions that will notify specific users when a resource's configuration is changed externally, which lays the groundwork for providing proactive management to counteract unwanted changes in your enterprise.