The short answer is no, the CLI doesn't allow you to setup alerting.

The longer answer is, you can write some Java code to do the same thing as you would in the CLI, then deploy that as a server plugin. See: rhq/modules/enterprise/server/plugins/alertdef-rhq as an example.

I think there's a real need for the possibility to export and import alert templates, and it should be a standard feature. This way you could create and test alerts in a test-env, then import them into production. Of course it should also be able to do this through the CLI.

There is an RFE where an export/import plugin has been made, but not sure about the progress, it's been quiet.

https://bugzilla.redhat.com/show_bug.cgi?id=535829

If you had a server plugin that could interact with alert templates, and created a server plugin control, and had this exposed via the CLI, I think this could be done without actually touching the server code. Although I'm not sure, because the server controls are restricted to Configuration settings only, you'd have to serialize the rules (XML, JSON, Java object serialized as an array in Base64.).

The method would be something like:

addAlertTemplate(int resourceTypeId, String alertDefinition).

See Bug 1068816 for exposing server plugin controls.

We have an extensible implementation of data sync in the server (rhq/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/sync at master · rhq-project/rhq · GitHub) but currently only system settings and metric templates are handled. The problem with alert definitions and other types of entities (like users or roles, which would be handy to sync, too), is that they basically have relationships between each other that might or might not be present on the "import side" and even if they were, the IDs wouldn't match so some other kind of matching mechanism would have to be employed.

In case of alert definitions the only difficulty is that of notifications - they can reference arbitrary other entities in the system and being pluggable (even though the GUI doesn't directly supported), the import side doesn't have to even have the type of notification available.

Consider for example the Resource Operation notification - it can reference arbitrary resource in the inventory (internally using the resource id), or CLI Script, which references a package of a script file inside some repository in RHQ...

I haven't tried the plugin from Bug 535829 – RFE: Add import export for alert definition and possible metric schedule templates but it doesn't have sourcecode attached so I cannot judge how and what it does. By quickly looking at the example XML files, it doesn't seem to export notifications at all, which is one possible solution of the problem but IMHO not a good one

Code contributions are more than welcome but I'd like to avoid the server plugin approach in favor of extending the existing sync infrastructure.

I had no idea about this feature: https://docs.jboss.org/author/display/RHQ/Design+-+Configuration+synchronization

It does seem like the right place to add that feature, but trying to convert a bunch of alert definitions into a configuration XML tree seems...tedious. Can't the system deal with serializing/deserializing Java objects in a more natural way?

Alert definitions can be pushed via REST API, currently for individual resources only. If you can speak python, you can use and contribute python client designed to test alerts. See jon-tests/alerts at master · RedHatQE/jon-tests · GitHub . You might also want to check out jon-tests/alerts/baselines at master · RedHatQE/jon-tests · GitHub . There is support for selecting resources based on their path in resource tree. This allows you for example to say "I want to get alerted when every WAR file goes down". Currently selectors work only for resource name, but can be extended to resource type. Or you can still use raw access to REST API, This sample could help you samples/rest-api/python/create_alert_definition.py at master · rhq-project/samples · GitHub as it should be the complete list of condition and notification types.

The export file is meant to be editable by the user before the import - they might not want to import everything, tweak something, etc, so XML has been chosen as a format for achieving easy machine processing as well human editing capabilities.

For example metric templates use JAXB to ease the tedium of converting to and from XML and there's a reusable base-class for exporting of JAXB-based entities. The import is then fairly easy, too.

It's hidden here http://sourceforge.net/projects/rhq/files/rhq/rhq-4.11/