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