Skip to end of metadata
Go to start of metadata

Roadmap

History

All of the previous releases for RHQ are listed with information about new features and bug fixes.

RHQ 4.2 (October 31st, 2011)

  • Resource Configuration
    • better drift support
  • Server Enhancements
    • enhanced config sync
    • Support for PostgreSQL 9.1
    • performance enhancements
  • UI Enhancements
  • start supporting a REST api to have some endpoints around and to play with it.
  • Resource Support
    • enhanced JBoss AS 7 plugin
  • bug fixes

RHQ 4.3 (originally planned for late January 2012, released on March 8th, 2012)

  • UI Enhancements
    • update of GWT / SmartGWT to support more modern browsers
  • Bug fixes
  • Better REST API support
  • Option to dump the system state to the server log in order for diagnosing

RHQ 4.4 (around Mid April 2012)

  • Improvements in availability handling
  • better as7 support
  • increased test coverage
  • exporting of reports
  • Performance enhancements

RHQ 4.5 (planned for around mid of August 2012, released on September 27th, 2012)

  • Plugin I18N
  • more REST work
  • Changes in charting (replace the old struts/JSP code and replace with a GWT solution; GSoC work)
  • Build with maven 3
  • Running on JDK 7

RHQ 4.5.1 (released on October 4th 2012)

  • Two bugfixes for RHQ 4.5.0

Releases in the Works

RHQ 4.6 (planned 

  • Removal of web services
  • Removal of (for a long time not built 

Future Releases

These features are almost certainly going into a future release of RHQ. We like 'em.

  • TBD

Wishlist & Ideas

These are ideas and things that could be nifty to include but that don't have a plan yet.

Server & Database

Inventory & Resources

Alerting & Resource Monitoring

  • Add mod_jk monitoring
    • What kinds of metrics could be collected?
  • Allow for different availability check intervals depending on resource or resource type to e.g. check "important" resources more often.
  • A syslog alert sender plugin that can talk to remote syslogd to deliver alert notifications
  • Alerts based on total group measurements
  • Combining data from different resources and types to trigger alerts on this combined data
  • Allow to create derived metrics in a sense that the metric is the result of some computation like e.g. the difference of created vs. destroyed session bean instances. Or full servlet execution time minus some SLSB method time and so on.
  • Design - CallTime 2
  • Design - System Events
  • Send alerts based on trends
  • Track downtime to help monitor SLAs
  • Availability alerting – not exactly or not all of what users expect (i.e. down and has been down for 10 minutes)
  • Alert sending schedules (bucketing)
    • instead of getting alert notification storms, allow the user to configure when he/she should get notifications; so the system will queue up notifications and then send, in a single email, all queued notifications every 10 minutes for that user
  • composite alerting
    • instead of an alert definition being tied to a single resource or a single group or a single type (alert template), allow each alert condition to be related to a resource / group. this way you can say "if average web server group metric is <foo>" or "if average app server service metric is <bar>" or "if database metric is "yadda" then alert
  • complex alerting
    • more flexible alert condition processing - today we only support 'AND' vs 'OR' - let's support complex conditions such as (a AND (b OR c))
  • in-line call-time instructions
    • instead of forcing users to go to our documentation to figure out how to instrument their WARs for call-time data collection, make the web.xml snippet and instructions available in the monitor>response sub-tab itself. this way users go there, realize they haven't instrumented their app, and can easily copy/paste into their application's web.xml
  • in-line call-time enablement
    • instead of forcing the users to go monitor>schedules to enable call-time data on the server-side for a resource (or group) enable them to click a quick link within the monitor>response tab which will enable the appropriate schedule automatically...or, at the very least, provide a link that takes them to monitor>schedules with instructions on what to do (this means that we should always keep the monitor>response sub-tab enables for resources that support it)
  • in-line call-time setup
    • instead of forcing users to go to inventory>connection, allow viewing and alteration of the response time properties (log file, url excludes, url transforms) in line with the tabular results
  • in-line event source setup
    • instead of forcing users to go to inventory>connection, move the creation to a new sub-tab called event>sources (or even in-line the viewing/editing of event sources at the top of the audit trail / table

Provisioning & Content

  • A standalone (Swing?) bundle creation tool. Bundles are the way to provision complex software installations onto managed machines. There is some support for creating bundles already (e.g. bundleGen and some cli scripts), but those could become more comfortable for the user to use.
  • Finish group-wise content functionality
    • Push this EAR out to that cluster; update (in rolling fashion) this clustered WAR

Resource Config

UI

  • Incorporating third-party GUIs into the RHQ GUI
  • Better subtab nav / better alert definition subtab view

    jshaughn: the default alerts subtab is definitions. Would be nice if this list view gave some indication of alerts generated for the listed defs. today you have to click again and go to the history subtab to see if anything actually happened. maybe not a big deal given that alert notification is probably the primary mechanism for knowing if something happened
    joseph: would be nice if users could hover over the alerts main-tab, and the sub-tabs would be auto-visible options to choose from before clicking
    ips: jshaughn: +1. in addition to having an Alerts (Count) colun, we could potentially also add a Last Fired column with a dateTime
    jshaughn: both of those would be nice
    jshaughn: i like the subtab hover a lot, i hate having that multi-step process to get where I'm going
    jshaughn: would be very useful for Inventory tab as well
    joseph: yeah, preview functionality is not only bad ass, but often times actually useful too ; )

  • resource "actions"
    • either right-hand side panel (collapsable) vs. pop-up menu somewhere on the content area vs. quick action icon (next to avail check and favorite badge)
  • ajax feedback mechanism
    • add an "in progress" spinner to all pages when gwt is doing something async - this might be done at the global level for all pages if there are any async things happening, or perhaps it should be relevant to the content area that is doing the async work.
  • event>source sub-tab
    • move event sources out of plugin config into event>configure sub-tab to sit alongside event>history sub-tab - this will also allow event source reconfiguration without having to restart the agent-side resource component, and allow for a more directed/concise UI for group-wise updates of just the event logging stuff
  • search trees
    • searchable resource / group trees - a tree showing search results might be a flattened but disambiguated result list, or it might be greyed inner tree nodes
  • parameterized web context
    • make coregui web context a configurable parameter as part of the build (<address>:7080/<context>/) so that we can have, for example, "/rhq" or "/jon"

CLI & Server Scripts

Resource Scripts

Performance

  • Improve the availability reporting lag
  • precompute resource disambiguation
    • pre-compute resource disambiguation / lineage / hierarchy - the read/write profile is heavily weighted towards the read-access since nearly all fragments of all pages across the site need to be disambiguated. this would also enable us to easily expose lineage data via the remote API, instead of disambiguation being a UI-only thing

Agent

Logging & Reports

Translations for the UI & docs

  • Provide translations of e.g. Alert messages or Installer messages

Builds

  • maven build forking
    • fix maven build to fork javac for most (all?) modules, this will lower the maximum memory requirement (Xmx) when building from scratch, as well as lower the needed memory when building individual modules (the common case)

Backburner 

UI changes

Resource Configuration

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