[ This is the first of a series of postings describing where we stand with RHQ and where we may want to go to. ]
As many of you already know, RHQ is the upstream of JBoss Operations Network (JBoss ON) and so RHQ is following the requirements of JBoss ON.
RHQ has released 4.9 in September 2013 and is due for another release. That next release will include some performance enhancments on inventory syncing and agent footprint as well as a lot of fixes since RHQ 4.9. This next release is supposed to happen within the next month.
The RHQ team recently had a face to face meeting in Brno at the same time that the WildFly team was there as well. There are a few photos available ( and ) but we missed to create an all-team photo.
Some of the outcomes of that meeting are:
- RHQ source code will definitively be moved from FedoraHosted to GitHub in the near future.
- RHQ will in the future use the JIRA instance at jboss.org instead of Bugzilla (timing unknown at this point).
Those two actions will make it easier to contribute in the future when you already have an account at jboss.org
From a technical standpoint, we will tackle the following in the near to mid term - please comment on the respective wiki pages:
- Audit Subsystem 
- "Canned DynaGroup expressions" 
- Add support for https connections of the as7-plugin
- Add support Bundles and Drift for the Domain mode of as7/WildFly
- Provide a mechanism for out-of-band signaling of state and events from the agent to the server  (the current proposal on the wiki is a first draft to illustrate the idea and needs much more work).
- Implement signaling of as7/WildFly "dirty" state over the mechanism in the previous item
Of course we were also talking about the longer term and here mostly about two items:
- UI: The current dependency on the SmartGWT widget set becomes more and more problematic as SmartGWT is not able to keep up with all the browser changes. In addition, the end of life of GWT DevMode is also reducing our ability to further improve the UI.
We have thus decided to investigate other options like using Angular.JS for further UI work. We will create a separate UI project on the RHQ GitHub account  and will create a UI that can be dropped into RHQ to get more insight how such a Angular.JS driven UI could work for RHQ. This Angular UI will talk via the existing REST-interface to the RHQ server.
- Agent: Our current agent is a powerful workhorse, but has its shortcomings. One of those is its runtime footprint that is currently addressed. But even afterwards we want to try to reduce its impact, so that it is easier to run the agent on managed systems.
The other part is that the agent currently is only extensible in Java, while operations people are often much more versed in languages like Python. Also the possibility to ad-hoc define some metrics to be evaluated is rather limited (especially when it comes to arbitrary MBean attributes).
This means that we will evaluate alternatives to the current agent and also to evaluate how the current agent can be enhanced to support polyglot and smaller runtime environments.
In addition to the above we also were talking about enhancing the Alerting subsystem and to introcude a 2-phase-discovery to improve on some of the shortcomings of the current resource discovery .
Last but not least we want to thank all contributors for their suggestions, bug reports, enhancement requests and code submissions.
Heiko on behalf of the RHQ team