The RHQ CLI provides a way to manage resources more easily than the UI. I have a couple of RHQ CLI scripts that go into my crontab. One example is just having RHQ add things to its inventory from the queue automatically. One is clearing certain alerts after a number of hours. It would be better, though if RHQ itself had a way to execute JavaScript (o Python) scripts itself directly, as well as a way to schedule execution of these scripts. This would simplify administration a bit since: 1) Those scripts would be kept in the database with history etc. 2) Execution could be done using Quartz not cron, so it's not tied to a single host, it could run on any server. 3) Better visibility to administrators. Things like history, when it was added or disabled, etc. (I would not get too carried away here, though.) This ties a bit into this discussion: https://community.jboss.org/thread/212115?tstart=0 I want to have RHQ remove resources that were removed externally on a periodic basis. Defining what those are is particular to every site. Building a UI for this would be much more work and less flexible than coding some sort of script for it. Note that RHQ could come with some scripts that may do many of the things administrators want to do. Maybe one script could update agent plugins on a daily or weekly basis? Or like I do, automatically add stuff to inventory hourly.
Lukas, we already have the possibility for server side plugins to be scheduled by cron expressions. Could our facility to run alerting cli scripts be extended for general purpose scripts, as we already have the upload and content side of things and also the "container" to run the scripts? Elias' proposal looks like a great addition to me.
This has been on my mind from basically the day one of scripting on the server. Unfortunately other things have had higher priorities. The ability to run individual scripts on a schedule unfortunately doesn't play well with server-plugins "control" schedules. The controls of the server plugins are statically defined in the descriptor whereas the scripts are user-defined. So we'd probably have to create a new UI/remote API to manage the script schedules (we could still store them in the repos, but the schedule is something we don't have a place for yet. Also, the scripts could be "tied" to a number of "entities" - system wide, individual resources, groups, users, which adds to the complexity of the API/UI (but that could be alleviated to some extent by supporting passing "arguments" to the scripts, which is also an RFE for the scripted notifications ;) ). One of the other things I had in mind was to have the ability to define script-driven "wizards" that an admin could define for the users to then run - but I'm not sure this is of much importance as this is basically an UI only thing - basically such user-defined wizard would provide the configuration for a script to run with.