On 08 Jan 2015, at 19:17, John Sanda <jsanda@redhat.com> wrote:

What do you think about deploying rhq-metrics as a WF extension? 



This is my ultimate goal and the reason for many of my questions. In order to leverage rhq-metrics in wildfly, it’s needs to be properly integrated and have a reasonable out-of-the-box experience.

Some of my contributions (wildfly-monitor, cassandra-subsystem) have been intended to provide the pre-requisites to further integrate rhq-metrics. 

However we face some challenges to fully integrate rhq-metrics as a wildfly extension, including the corresponding subsystems:

a) Support for domain mode

To support the wildfly domain mode, we need to know how the metrics components are intended to be used in multi node environment (aka several vm’s operating as a whole)

It’s unclear to what degree the data partitioning and retention rules apply to such an environment. The question is true for other jobs that require some level of coordination (i.e. processing rollups).

IMO this is the biggest gap at the moment: these requirements are unclear/undefined and all examples currently assume a single, standalone wildfly instance.
 

b) API and service dependencies

Integration on the level of a wildfly extension comes with a lot of constraints. Most notable the availability of certain API’s and service at this level. Most of rhq-metrics components assume the availability of a full EE7 stack and it’s API’s. We can certainly discuss an extension of the low level API’s that wildfly provides to certain degree, but it will never provide the full EE7 API for extensions.

At the moment this is a real blocker to further integrate rhq-metrics. There are ways to circumvent these problems, but only by providing dedicated implementations of some rhq-metrics-core API’s. This effectively prevents re-use and would put us in a position of having to catch up with the latest functional enhancements.

Regards, HeikoB