Bug 784953 - JON 3.01 RC#1 CLI samples ... usability issue with drift.js
JON 3.01 RC#1 CLI samples ... usability issue with drift.js
Product: JBoss Operations Network
Classification: JBoss
Component: CLI (Show other bugs)
JON 3.0.1
Unspecified Unspecified
unspecified Severity high
: ER01
: JON 3.2.0
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On: 852145
  Show dependency treegraph
Reported: 2012-01-26 13:57 EST by Mike Foley
Modified: 2014-01-02 15:39 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Task
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Foley 2012-01-26 13:57:57 EST
Description of problem:  CLI samples ... usability issue with drift.js

Version-Release number of selected component (if applicable): JON 3.01 RC#1

How reproducible:

Drift.js (and the other samples) are really not usable out of the box.  A gap exists before the .js files can be used.   The scripts contain utility functions, but they are not runnable.  There should be some kind of wrapper that allows these to be utility functions to run.  Eliminating or reducing these barriers will help the customer experience, increase adoption, etc ..
Comment 1 Mike Foley 2012-01-30 11:25:55 EST
12/30/2012 BZ triage meeting mfoley, ccrouch, loleary, asantos
Comment 2 Lukas Krejci 2012-02-14 05:51:37 EST
The proper solution is to implement the import mechanism that the scripts could use. I.e. something akin to http://requirejs.org (note that this is not that simple, because ideally, the mechanism should work both in the CLI proper and in the serverside CLI alert scripts - but requirejs has a pluggable script loader mechanism, so maybe we would be able to hook it up on the serverside with the scripts stored in RHQ repos).

A workaround might be to add ability to load multiple script files using the -f commandline option. This however would not be so user friendly anyway, because the user would need to know the requirements of the scripts upfront and specify them in the -f option in a specific order.
Comment 3 Charles Crouch 2012-02-14 19:14:39 EST
Given Lukas' comment this is not going to be resolvable in 3.0.1. Resetting for *consideration* as part JON3.1.0.
Comment 4 Lukas Krejci 2012-03-22 11:05:34 EDT
Discussion of our options for implementing the script modularity: http://rhq-project.org/display/RHQ/Script+Modularity
Comment 6 Larry O'Leary 2012-11-27 15:12:57 EST
This is an action/enhancement requested by QE to make testing easier. The support for modular/includes in the CLI appears to have been implemented in upstream bug 852145.

Resetting for triage in 3.2.0. Hopefully something useful will happen once we realize that this is already available upstream and just needs to be brought into the product.
Comment 7 Lukas Krejci 2013-01-30 11:25:39 EST
In RHQ 4.6 codebase (or maybe already in RHQ 4.5.1 actually), the following has been done:

1) The scripts in the "samples" directory in the CLI distribution were left intact.
2) A new subdirectory called "modules" was added under "samples", which contains the "modularized" versions of the scripts in samples.
3) The modularized version of drift.js can be loaded in the CLI by issuing the following command:
var drift = require("modules:/drift")
4) The functions from the drift.js file are then available through the "drift" variable in the example above.

Note that the the location from where the "modules:/..." scripts are loaded is configurable and defaults to $CLI_HOME/samples/modules. It can be changed by passing a different path using "rhq.scripting.modules.root-dir" system property.

I.e. starting the CLI like:
RHQ_CLI_ADDITIONAL_JAVA_OPTS="-Drhq.scripting.modules.root-dir=<ABS_PATH>" $CLI_HOME/bin/rhq-cli.sh

will set the base path from where the modules are loaded (using the "modules:/" path prefix) to the <ABS_PATH>

(no code change here, so setting the status to ON_QA straight away)
Comment 8 Larry O'Leary 2013-09-06 10:32:31 EDT
As this is MODIFIED or ON_QA, setting milestone to ER1.
Comment 9 Mike Foley 2013-09-13 15:43:14 EDT

unconnected$ var drift = require("modules:/drift")

unconnected$ drift.

createSnapshot   diff             fetchHistory
unconnected$ drift.

Note You need to log in before you can comment on or make changes to this bug.