Skip to end of metadata
Go to start of metadata

Dynamic Metadata

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.

General Ideas

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?

High level design

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.

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.

Example of the JMX plugin supporting dynamic mbean metadata discovery:

On the server...

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.

On the agent...

Committed dynamic resource types will need to be synced and persisted on the agent so that it can perform discovery on them.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.