When a server-side plugin is defined, it can indicate properties the RHQ user must provide to govern how a particular "instance" of the plugin will perform. These properties, like many others in RHQ, leverage the configuration subsystem pieces (XML schema, domain model, database tables, etc.).
Originally, the configuration subsystem supported enumerated values. However, these values are statically defined in the plugin descriptor at the time of writing the plugin. The need arose to be able to populate these enumerated values at runtime from a variety of different sources.
Initially, these changes are only supported by server-side plugins. Future work may extend this functionality into agent-side plugins as well.
The following cases were identified as desired uses of dynamically retrieved property values:
At initial configuration page rendering, the values of a property are requested from the RHQ (the database).
Initial use case involves tying into users & roles, however it is likely that retrieving resource type and package type information is needed as well.
At initial configuration page rendering, the values of a property are requested from a server-side plugin at the time they are needed.
Technically, not needed immediately. Use case comes from content requirements that are no longer valid. However, it still seems like a good thing to have, and at very least need to be taken into consideration by the solution.
Sprint Ending: January 25th, 2009
The first phase will incorporate the base changes needed to the configuration subsystem to support dynamically populated values. It will also provide the ability to use RHQ data (from the database).
The property types as a result of this change will include one for dynamic properties:
simple-property
map-property
list-property
dynamic-property
For phase 1, the dynamic-property tag always results in a drop-down box allowing the user to select a single entry. The value source (database or plugin callback) will provide a list of strings to use as both the display data in the UI's drop-down box as well as the value used when an entry is selected.
The dynamic-property tag will require a child tag to indicate the source of the dynamic values, similar to how constraints are added to simple-property tags. Using an XML schema choice will make the one and only one nature of the source schema enforceable.
For this phase, the only value source available is the database source. The database source requires a key to indicate where to retrieve the values. The following keys are supported in phase 1.
|
Key |
Description |
|
users |
List of all users in the system. |
|
roles |
List of all roles in the system. |
|
package-types |
List of all package type names. |
Once the initial infrastructure is in place it should be relatively easy to add new keys. This first pass is to meet the needs of the use case and as a demonstration of the ability.
Again, the lookup for each of these keys will return a list of zero or more string values to be used in the UI display to the user and the value of the property itself. For instance, if the user selects the UI drop-down option "RHEL5-u3-i386", that is the exact value that will be passed as part of the plugin's configuration.
No scheduled sprint
The second phase will add in support for calling out to server-side plugins for property values.
Going forward, it would be slick to be able to support property relationships. For instance, changing the value of one property results in one or more other properties either appearing or having their values populated at the time.