Recently I wanted to demo how to do something in RHQ’s CLI. It was a fairly simple thing but our API being what it is, built for and implemented in Java, the result ended up being kinda verbose and didn’t exactly look like your modern fluent Javascript code.
rhq
Paging through the results is easy, right?
RHQ 4.5.0 (which we released today) contains a great deal of scripting enhancements that I think are worth talking about in more detail. In my eyes, the changes make the scripting in RHQ ready for serious use.
Recently, we’ve started using Mockito and PowerMock in our testing. I won’t explain mocking and why or why not you should use it, but I want to share my experience with using PowerMock.
In the past few weeks I was quite busy refactoring RHQ’s CLI and scripting integration. Funnily enough it all started because we wanted to add the support for CommonJS modules to our javascript interface. During the course of the refactoring, I found out that I’m actually heading in the direction of completely separating the "language" support from the rest of the RHQ, which then only speaks to it through the Java’s standard scripting APIs which are language independent.
Historically, RHQ has had a little bit of a problem with test coverage of its various (agent) plugins. There is a multitude of problems with testing these but the following two are, IMHO, the main ones:
In RHQ we let the users provide scripts that can be run when an alert fires. This is great for automation because the script can do anything the users can do with our remote API. But the users of course can write a script like this:
I watched the great demo of the XMPP server plugin for RHQ from Rafael Chies. Rafael is using a custom DSL to query the RHQ server for information but I thought that that really shouldn’t be necessary - it should be possible to use an ordinary CLI session behind this. Granted - the "query language" of our remote API is more complicated than the simple DSL Rafael is using but at the same time, the API we use in the CLI is much more feature rich and I wouldn’t have to reimplement any of it if I was able to "blend" the CLI session with the XMPP chat.
In RHQ we use the Augeas library to do the configuration file parsing and updates for us in some of the plugins. Augeas in itself is pretty cool and the language for describing the structure of arbitrary configuration files and howto update them is pretty powerful. The only downside to using Augeas is that it is a C library and we therefore have to bind with it and use it more carefully so that we don’t leak its native resources that aren’t under control of JVM’s garbage collector.
We are currently starting to think about what would it take to implement exporting and importing various "configuration" elements including metric and alert templates, server configuration, dynagroup definitions, users & roles and possibly other "entities" between different RHQ installations.