3.2 Release Notes

The overall server installation process has been streamlined in JBoss ON 3.2 as part of upgrading the underlying application server to JBoss Enterprise Application Platform 6.

The biggest single change is that there is no longer a web-based configuration process. All configuration is performed by the installation script, based on the values in the rhq-server.properties file. This makes it much easier to automate server provisioning.

There are other changes that simplify the installation process:

Starting in JBoss ON 3.2, all numeric monitoring data and aggregated values are stored in a dedicated NoSQL database, the JBoss ON metrics storage node. Every server is either installed (or upgraded with) a metrics storage node or must point to an existing storage node, in addition to the SQL database used to store all other JBoss ON resource data and configuration.

There are a number of performance benefits by splitting the monitoring data into a separate storage node. This improves the performance of the backend SQL database by moving heavy write traffic to a separate database, and it also frees resources for intensive features like drift snapshots and stored bundles and content. Additionally, the NoSQL database cluster can be easily expanded to include additional nodes, even after server installation. This reduces the structural database bottleneck that has historically limited metric collection levels.

The metric data storage changes primarily affect the installation process:

There is an option with the rhqctl upgrade script to migrate all existing monitoring data out of the SQL database and into the new metrics storage database. If that option (--run-data-migrator) is not used with the upgrade, then the old monitoring data are lost.

Previous versions of JBoss ON used the rhq-server.sh|bat script to install and start the server. This has been replaced by the new rhqctl script. This script has specific commands to install and upgrade the server, to install and upgrade associated components such as the agent and a metrics storage node, and to start and stop the server, agent, and storage node.

This new rhqctl control script still uses the rhq-server.properties configuration file for its initial configuration.

In previous versions of JBoss ON, there was a single (extremely powerful) permission for bundle operations: MANAGE_BUNDLES. This allowed complete access to everything related to the bundle configuration: resources, groups, bundle content and configuration.

In JBoss ON 3.2, the bundle permissions have been broken into multiple permissions, at three levels:

This new permissions structure introduces the idea of a bundle group. A resource group is a defined group of resources and access controls can be set based on what resource group a user has permissions to. Likewise, a bundle group is a defined subset of existing bundles, and a user is granted access to a specified group. A user can only view and manage bundles which belong to that given bundle group.

These changes allow much better control over content streams and resource maintenance, while providing visibility (without power) to managers and analysts who require clarity about development and production content.

Dynagroups are dynamic groups that are created through a versatile expression language which filters members on criteria such as name, parent or child resources, resource type, and version.

Previously, a dynagroup expression evaluated the entire inventory when determining group membership. A new criterion has been added, memberof, which means that members of the dynagroup are evaluated from the members of an existing group. In other words, the dynagroup is a subgroup or subset of an existing group.

This is especially useful in creating fine-grained access controls and other management operations.

Previously, the classes and methods to create dynagroups were internal. Therefore, dynagroup expressions could only be created and edited through The JBoss ON GUI. The updated remote API (used by JBoss ON server-side scripts for alerts, the JBoss ON CLI, and other clients) now includes the full GroupDefinitionManager to create, edit, and delete dynamic groups.

Previously, there were limits on sites where JBoss ON could download bundlefiles; only the URL could be specified, no authentication credentials. In practice, this meant that most commonly bundles were uplooaded from a local system to JBoss ON.

Starting in JBoss ON 3.2, JBoss ON can pass authentication credentials to any remote site that is specified. A bundle definition can be created that references the SVN repository URL and then authenticates to the SVN repository (either through standard HTTP or over HTTPS). From there, it pulls in the bundle archive.

This makes it easier for bundles to be pulled directly from a build system.

A number of new metrics related to session management and web application responsiveness have been added to the JBoss Enterprise Application Platform 6 plug-in for deployed web context (WAR) resources. These include:

The charts used to render the monitoring graphs have been updated.

Previously, JBoss ON agents could not be removed through the JBoss ON web UI. They could only be removed from the host system, and then the platform entry had to be imported into the inventory (if it wasn't already) and then removed from the server's inventory. Removing the platform resource ultimately removed the agent's registration.

Now, there is an option in the Administration > Agents page to delete a selected agent. This removes the agent's registration information and its entire inventory directly, without having to go through a platform resource.

Previously, an alert condition within an alert definition could not be edited. It had to be deleted and then replaced by a new condition.

Now, alert conditions can be edited within the definition.

The JBoss ON web UI has long allowed adminitrators to schedule an operation using a cront string. However, it was not possible to use a cron string when creating operations in the CLI or scripts. The OperationManagerRemote remote API method has been updated to allow the schedule to be created in cron syntax.

Previously, all SNMP alert notifications sent out the same trap OID, which was specified in the global configuration for the SNMP alert sender plug-in.

Starting with JBoss ON 3.2, it is possible to set a different OID within the alert definition. Now, the OID set in the global configuration is used as an enterprise identifier. Then, the SNMP trap OID set in the alert definition is used in a special attribute called a variable binding along with other identifying information for the alert.

It has always been possible to ignore discovered resources in the discovery queue. Now, it is possible in the Administration tab to define resource types which will always be ignored and blocked from the inventory.

This is exceptionally useful for server types which have a large number of child resources. Child server and service resources are automatically imported when its parent is imported. For example, a JBoss Enterprise Application Platform resource may have hundreds of MBean child resources; ignoring that resource type can make managing the JBoss Enterprise Application Platform server easier and more maintainable.

Resource availability is checked on a schedule (such as every minute for servers and every 10 minutes for services). This meant that there could be a gap between the collection time and the availability state displayed in the web UI or returned by API calls.

JBoss ON 3.2 changed availability checking so that it is performed every 15 seconds when a resource page is open or when a call is made about the resource. This allows for near-immediate visibility of when the state of a resource changes.

When a resource is not being viewed, the normal availability schedule applies.

Previously, the Scheduled Operations portlet in the Dashboard listed operations scheduled on individual resources. Now, the list includes operations scheduled for compatible groups along with the resource operations.

In JBoss ON 3.1, a new REST API was introduced as a tech preview feature.

Starting in JBoss ON 3.2, the REST API is fully supported. The REST API, along with some example applications, is available with the JBoss ON server:

https://server.example.com:7080/rest

Along with being supported, the REST API has been extended to include additional functionality, including:

With Active Directory and other LDAP directories, the membership lists returned with LDAP authorization could exceed the search limits set for the directory. This could lead to inconsistent or incomplete group information when working with LDAP groups in JBoss ON.

JBoss ON 3.2 implements LDAP paging controls for search results, which helps improve the performance for handling large groups by breaking the group results into pages that are within the search limits.