Friday, December 11, 2009

New RHQ Beta Release Is Out!

The RHQ project is pleased to announce the first developer release of the RHQ 1.4.0 management platform. This developer release, 1.4.0-B01, provides an early look at the new features which are being planned for the 1.4.0 general release.

Note that we've pulled in the Jopr plugins into this RHQ release. So, consider this new RHQ release a merging of both the RHQ project and the Jopr project.

Note: do not upgrade any existing Jopr or RHQ installs with this build! Specifically, the Jopr plugins in this new RHQ build are versioned differently and will not upgrade your existing Jopr plugins. We'll fix this in a later release.

Now, here are the particulars if you are interested in learning more:

Saturday, December 5, 2009

RHQ Server Plugins - Innovation Made Easy

RHQ is introducing a major new feature - server plugins. I know what you are saying... "ho-hum, another 'plugin mechanism'". It is true that this is analogous to the RHQ Agent plugin functionality - just as you can write your own agent plugins to extend the types of resources an agent can manage, you now have similar capabilities in the RHQ Server.

But when you examine the capabilities of this new server plugin subsystem, you will notice that you now have access to the full breadth and depth of functionality that the core RHQ Server code has, without having to modify core code. Using server plugins, you can plugin your own management code to the RHQ Server, allowing you to add to the existing core management feature set. With a minimum of a single Java POJO class bundled with an XML descriptor, you can now extend RHQ server functionality in areas you couldn't with the agent plugins. The ability to innovate new features and capabilities will be much easier.

I put together a demo for an illustration of the potential that server plugins open up. If you are interested, the demo's plugin code can be found here. This sample plugin has a single Java POJO and an XML plugin descriptor.

The core of the server plugin container infrastructure is checked in. More work will be done to enhance it further, but it works today. What the RHQ team is currently working on is adding support for different types of server plugins.

For example, the demo mentioned above uses a "generic plugin" - that is just one type of server plugin. This is a "catch-all" type of plugin - all other plugin types will essentially build on top of the same capabilities of a "generic plugin". This generic functionality allows for the server plugin developer to write Java code that gets embedded in the server and runs. Each plugin can define a plugin component (much like an agent resource component in an agent plugin). The plugin component is notified when lifecycle events occur (such as when the plugin is started and stopped). The generic plugin can also utilize the server's scheduler to run jobs on a periodic basis. For example, if I want to generate management reports, I can write a server plugin that has a job that runs every day, generating reports when it runs (in fact, this is what the demo above illustrates).

Other types of plugins that are actively being developed are:

  • Content Plugins - these will allow you to define remote content repositories so you can pull in software from those remote locations to be pushed out to remote machines.

  • Alert Plugins - these will allow you to plug in remote alert destinations. Heiko has some great ideas on this and has already demoed a few of them. The one I like in particular is the alert plugin that integrates with Mobicents so when an RHQ alert is triggered, a voice message is sent to an administrator's phone. Very cool :)

  • Perspective Plugin - this is an extremely powerful type of plugin that will enable a developer to add additional graphical user interfaces to the core RHQ Server. There is a entire perspectives design, which will build within the server plugin infrastructure.

A lot more will be communicated about these server plugins as they are built out. But you can still do server plugin development today. Documentation is available, and we'll be building out more documentation as we get further along.

Thursday, December 3, 2009

New Source Repository for RHQ

Recently some changes have been made to the infrastructure used by the RHQ and Jopr projects.

We have consolidated the work into a single project.

We have also changed from the use of JIRA to Bugzilla. All JIRA issues have been ported over to the RHQ Bugzilla project.

You may see changes to my previous blog entries - I'll go through them all to edit the links so they point to the new places, as opposed to the old, outdated SVN and JIRA locations.

Tuesday, December 1, 2009

Configuration Remediation

There was previously some requests for RHQ to support "configuration remediation". In short, it would be nice to "freeze" a resource configuration such that if that configuration ever changes for whatever reason, we want that configuration to immediately revert back to its "frozen" configuration state.

I spent a couple of hours coding up a prototype to show this feature in RHQ. See the flash demo here.

There are a few things to say about this.

First, specifically about configuration remediation - this demonstrates how easily it was for RHQ to support such a feature.

Second, and more generally, this effort illustrates the benefits of the RHQ architecture and the concept of "management at the edges". The code was added to the core configuration subsystem - it did not involve any one specific type of managed resource. Because of that, the couple hours that I spent adding this feature provided a wide array of functionality - I now have configuration remediation support for any managed resource that supports configuration. The storage of the configuration on the managed resources is handled at the edges by each manage resource's plugin. But the remediation logic is in the core server, independent of any managed resource that is out in the environment. So, not only was I able to quickly add a new configuration feature to RHQ, but that feature was immediately available across all types of resources without any additional effort.

What does this mean? It means, for example, that I can now freeze configuration of a JBossAS data source just as easily as I can freeze the configuration of my OpenSSH daemon (or any other managed resource that I can configure). On top of that, my RHQ users won't have to learn many different user interfaces or different mechanisms depending on what resource they want to configure - learn one user interface and you will know how to do this for JBossAS data sources, or OpenSSH daemons, or anything else.