SystemTapGui usage scenarios.

[Dave Brolley]

Hi Anithra,

Just to repeat and record what I was getting at during today's call...

It looks to me that one could accomplish just about any usage scenario 
by thinking of this in a modular way. We have:

o stapgui - a tool for creating stap scripts and visualizing the results 
of running them
o stap - a tool for compiling scripts on the local host
o stap-client/stap-server - a tool for compiling scripts on local or 
remote hosts
o staprun - a tool for loading/executing stap modules on the local host
o stapgui-server - the "lean" server you refer to is a tool for 
loading/executing stap modules on local or remote hosts

Given this set of tools, I think you can accomplish all of the usage 
scenarios below and likely additional ones as well. One essentially has 
the ability from a given host to use stapgui to create a stap script, 
compile it for the local host or any target running an available 
stap-server (via stap-client), load/execute it on any compatible host 
(via staprun or the "lean" server) and view the results in stapgui.

i.e., if we think of the "lean" stapgui server as a staprun-server, then 
there is no need to extend the existing stap-server to provide remote 
loading/execution of stap modules and, provided that suitable 
stap-servers are available, you may not need more than the "lean" 
stapgui server.

As for hard dependencies on the stap compile-server, stap-client has the 
same user interface as stap (with some client/server specific 
additions), so stapgui would only need to know to use stap-client when 
compiling for a target other than the stapgui host.

Does this make sense?

Dave

> -------- Original Message --------
> Subject: SystemTapGui usage scenarios.
> Date: Tue, 07 Apr 2009 21:10:56 +0530
> From: Anithra P Janakiraman <anithra@linux.vnet.ibm.com>
> To: systemtap <systemtap@sources.redhat.com>
>
> Listing the usage scenarios i can think of for stapgui. Please add to
> the list if i have missed something.
>
> 1. Client and Server running on the same local machine(a laptop?). In
> this scenario a hard-dependency on the compile-server might not be a
> good idea. The systemtap installation on the m/c would have the
> compile-server scripts, but ideally the compile-server will not be
> registered as a service in this case.
> 2. Client and server on different machines in a cluster environment. A
> lean server that only does execution with the compile-server taking care
> of compilation would be a good option, esp if the server does not have
> the required dependencies like debuginfo setup.
> 3.  A lean server, with the client doing the compilation and sending
> over the module to the server. The client and server would need to have
> an identical setup.
> 4.  The client , server and compile-server all on the same machine
> (possibly in a clustered environment) with the m/c running the server
> also running the compile-server service.
> 5.  The client running on a windows box. In this scenario access to the
> server's systemtap installation would be needed to list probes/functions
> and for syntax-checking.
> 6.  Multiple servers with a single client.
>
> Regards,
> Anithra.
>
>
>
>