public interface ResourceDiscoveryComponent<T extends ResourceComponent> \{
Set<DiscoveredResourceTypeDetails> discoverResourceTypes(ResourceDiscoveryContext<T> context);
\}
This design is for extensions to the RHQ resource typing system to allow for dynamically managed metadata. The most obvious use cases for this are scenarios involving integration with other systems that provide the necessary information for management and can be adapted to the RHQ system. Examples include JMX, which would be able to transform MBean Metadata information into the typing needed by RHQ. This would allow RHQ to manage arbitrary MBeans without having a specific plugin developed to support it.
The dynamic typing system would need to be able to dynamically add and update type information. It is likely that it would also be useful to allow the user some amount of control to choose the dynamic types allowed and even to adapt or augment them. As usual, we will follow the principle that this functionality needs to be usable by any plugin developer.
I see this as a separate inventorying system that runs along side the standard inventory discovery system. A new type of plugin component (a "ResourceTypeDiscoveryComponent") would be called out with metadata for placement inside the type system (e.g. run the DynamicMBeanTypeDiscoverer as a child of the MBean Server resource type). These type discovery components would run and send type discovery reports to the server. The server would then allow the user to choose and select which types to "commit" to inventory. Once committed the allowed types are synced to supporting agents so that discovery against the dynamic types could happen as normally happens with non-dynamic types.
Probably of secondary importance would be a system to allow the user to augment the dynamic metadata, choosing which properties are metrics, setting a "unit" type for a metric or altering the description or name of a discovered operation. These overrides would have to be maintained over updates to the metadata.
Also a core requirement is a canonical identification system for these types and a merging and compatibility strategy. How is versioning handled? What happens when the same mbean class has different metadata in one agent? What happens between multiple agents?
The plugin would still need to provide concrete implementation classes for both the ResourceDiscoveryComponent and the ResourceComponent. These classes would need to be pointed to by the discovered type metadata.
public interface ResourceDiscoveryComponent<T extends ResourceComponent> \{
Set<DiscoveredResourceTypeDetails> discoverResourceTypes(ResourceDiscoveryContext<T> context);
\}
The following is information that the type discovery would have to generate. We could, optionally, allow this stuff to be defaulted to with metadata allowing one to use XML to define defaults that are then extended by the discovery.
private ResourceType parentResourceType;
private String plugin; // set by the container
private String typeKey; // the name of the type
private String typeDescription;
private String discoveryComponentClassName;
private String componentClassName;
private ResourceCategory typeCategory;
private ResourceCreationDataType creationDataType;
private CreateDeletePolicy createDeletePolicy;
private ConfigurationDefinition pluginConfiguration;
private List<MeasurementDefinition> metrics;
private ConfigurationDefinition resourceConfiguration;
private ResourceSubCategory subCategory;
private Set<EventDefinition> eventDefinitions;
private Set<OperationDefinition> operationDefinitions;
private Set<ProcessScan> processScans;
private Set<PackageType> packageTypes;
private List<ResourceSubCategory> subCategories;
private String helpText;
Example of the JMX plugin supporting dynamic mbean metadata discovery:
<server name="JMX Server" discovery="JMXDiscoveryComponent" class="JMXServerComponent"
...
<dynamic name="DynamicMBeans" discovery="MBeanResourceDiscoveryComponent" class="MBeanResourceComponent">
<plugin-configuration>
<c:simple-property name="objectName" />
<c:simple-property name="nameTemplate" default="Dynamic MBean Type"/>
</plugin-configuration>
</dynamic>
Once types are dynamically detected the user would go to the "types management" page and choose which to "commit" to inventory thereby allowing discovery and import of their resources. The reason for this is that many dynamic type detection scenarios would likely found a lot of extra junk the user doesn't want in the system. Some MBeans will already be known by concrete metadata... other MBeans have no monitoring or management value.
Committed dynamic resource types will need to be synced and persisted on the agent so that it can perform discovery on them.