Change location of CLI samples
Lukas Krejci
lkrejci at redhat.com
Tue Sep 11 18:41:16 UTC 2012
With the introduction of scripting modularity in RHQ 4.5.0, it has become
possible to load scripts from various (non-local) locations.
Our samples are currently distributed in the CLI distribution in the "samples"
directory. But we also have a counterpart of samples on the server-side -
Administration-Downloads section contains an example alert script that users
can download, modify and use. This server-side script uses 3 of the scripts
that are otherwise in the CLI samples. It has no other option but to have
these scripts copy-pasted into the contents of the alert script.
You can see the script here in its entirety of 484 lines of code:
http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/server/container/src/main/downloadable-
resources/cli-alert-scripts/fix-bundle-deployment.js
Now if we were to distribute the CLI samples in a location that would also be
reachable from the serverside alert scripts, it would reduce to mere 2 lines
of functional code:
var bundles = require("rhq://downloads/bundles");
bundles.deployBundle(...);
Therefore, I would like to propose the following:
1) Put the scripts currently contained in $CLI_HOME/samples in a location on
the RHQ server so that it is reachable both by server-side and client-side
scripts.
2) Leave the samples in the CLI distribution, too, to a) keep the backwards
compatibility and b) enable their offline usage (even though that wouldn't
probably be of too much use to users).
For 1) we'd of course need to also provide UI section in the downloads.
Additionaly, the sample scripts as they are now would have to be "modularized"
- they currently assume they are loaded into the interactive CLI in certain
order before they can be used. But this is a rather simple if laborious
change.
The above is captured by http://bugzilla.redhat.com/show_bug.cgi?id=852169
(which also has a patch attached that implements the necessary changes ;) ).
What do you think? Do you have any objections against or ideas about the
above?
Thanks,
Lukas
More information about the rhq-devel
mailing list