CLI on server part 2

John Sanda jsanda at redhat.com
Mon Jan 10 18:58:46 UTC 2011


On 1/10/11 11:27 AM, Lukas Krejci wrote:
> Hi team,
>
> here's a short summary of Filip's and my discussion about the custom CLI
> scripts on the server and their possible usage.
>
> The basic idea is that the CLI scripts on the server should not only be
> defined as alert notifications but we should also enable users to execute
> scripts (or create schedules for executing them) on the server at any time.
>
> The scripts should be "attachable" to almost any entity in the system:
>
> -- resource type - the scripts could be used to mass create dynagroups,
> alerts, whatever
> -- resources - collect some non-trivial information from the inventory and act
> upon it accordingly
> -- groups - the same as for resources
> -- global scripts - not attached to anything, could be used as general purpose
> CLI scripts as they exist today remotely.
>
> The advantage of having the scripts stored on the server is that the users
> will thus have a common repository of scripts (reviewed by the admins) to use.
> An interesting twist to this could be a script exchange forum on the rhq-
> project.org where users could upload their scripts and discuss their usage.
> Such forum could provide us very useful information about the real-life usage
> scenarios and common problems our users face which we could use to further
> improve our product. Also, by having such an easy way of extending the
> functionality by simple javascript scripts, we could attract much wider range
> of contributors that wouldn't have to know java (which isn't the most popular
> language choice among our main target audience - the sysadmins).
>
> An interesting problem is how to render the outputs of such scripts. Obviously
> the script could write out a file to the server or we could just redirect the
> System.out somewhere (the browser?) but a richer UI would be ideal. We'd have
> to define a standard set of "renderers" that would display the results in a
> rich manner in the GWT UI (the good starting point here could just be able to
> render a list of resources, list of groups and a configuration, all of which
> we currently are able to display in GWT already).
>
> Obviously for all this to work, we need to come up with a store for scripts.
>
> Your thoughts?
>
> Thanks,
>
> Lukas
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
Other than for things where it is necessary, like scheduled jobs or 
custom alert scripts, I am not too keen on storing scripts on the 
server. It sounds to me like a document management system or an SCM tool 
would be a more appropriate tool for some of the things being discussed. 
With that said, I understand the need for storing scripts on the server 
in some form. I just hope we do not look to do things that are better 
suited by an SCM tool.

Here are a few areas that I think we can really improve on the CLI and 
hopefully attract contributors as well. They apply equally to usage both 
on the client as well as on the server.

* Documentation
Our docs are pretty minimal. I think users would really benefit from a 
cook book that demonstrates various capabilities. As a starting point, 
we could provide sample scripts for common work flows carried out 
through the UI. We also need better javadocs for our remote APIs. The 
interactive shell is extremely useful, and I think some form of 
executable documentation would be a really nice complement. I know that 
some languages (python and clojure are two that come to mind off hand) 
provide executable docs, and I find it really helpful.

A lot of our remote APIs are essentially asynchronous operations. You 
initiate some action, an audit trail entry is returned, and eventually 
that audit trail entry is updated to indicate the outcome of the 
operation when it completes. I do not think this is documented very well 
in most cases and could easily be a source of confusion for script writers.

* Reuse
One of the things I have found lacking when writing scripts is the 
ability to import/use functions and/or objects that exist in some other 
script. Let's say I have a script named util.js that provides some 
common helper functions. If I am working in the interactive shell, I can 
execute util.js so that any functions it declares will get bound in the 
current context. If I am working in non-interactive mode however, I do 
not have that capability. I know that there are some JS libraries out 
there which are rhino-compatible that provide this functionality. It 
might be worth looking at incorporating one of these into our CLI or at 
the very least study the libraries to get some ideas around we can 
provide better support for reuse.

* Higher-level APIs
We expose APIs in their raw form. In other words, the APIs we expose are 
the same used internally on the server and in various UI-initiated work 
flows. We need to consider how we can provide some higher-level, work 
flow-oriented APIs. Take deploying a war file for instance. We provide 
the necessary building blocks for scripting a war deployment to managed 
JBAS instances; however, those building blocks are not very intuitive 
unless you are intimately familiar with a good portion of the RHQ code 
base. I think we could look at making enhancements both on the 
server-side as well as on the client-side APIs.

I think we also need to consider providing some abstractions and better 
APIs for dealing with asynchronous operations / work flows. For 
instance, suppose I make a call to OperationManager to restart a JBoss 
server. Even if that call returns without error, I won't know until some 
point in the future (maybe a few seconds or maybe a few minutes) whether 
or not the operation was successful. If I want to write a script that 
does X if the server restart is successful or Y if it is unsuccessful, I 
have a couple options. 1) Use a resource proxy which is useful but has a 
number of limitations. 2) Cobbler together my own solution that might 
involve mulit-thread....yuck.

We can provide bigger and better building blocks on top of what we 
already expose, making it easier and less error-prone for people script 
various tasks and work flows.


More information about the rhq-devel mailing list