Re: SystemTapGui usage scenarios.

Re: 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.
>
>
>
>   

Re: SystemTapGui usage scenarios.

[Anithra P Janakiraman]

Dave Brolley wrote:
> 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
Hi Dave,

I'm not very clear with the usage of stap-server/stap-server  that you 
have described.
This is what i understood:
The staprun-server(stapgui-server/"lean" server) is to staprun what the 
stap-client/stap-server is to stap.
1. In a scenario where i create a script using stapgui, and i need to 
execute it on a remote machine - i use stap-client to create the module 
and use the staprun-server("lean" server) to execute the module.
2. In a scenario where i create a script using stapgui, and i need to 
execute on the same machine - i use stap and staprun instead of the 
stap-client and staprun-server

The problem i have with this is that it creates a "hard-dependency", in 
the sense , in scenario 1 if there is no stap-server the stapgui cannot 
be used. I would like to use stapgui even if there is no registered 
compile-server.

The alternative would be to check if there is a registered 
compile-server, if not use stap to compile on the  remote machine and 
use the staprun-server for execution. This is how others had interpreted 
you mail :).  Ananth, correct me if im wrong.

Regards,
Anithra.

>
>> -------- 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.
>>
>>
>>
>>   
>

Re: SystemTapGui usage scenarios.

[Dave Brolley]

Anithra P Janakiraman wrote:
> Hi Dave,
>
> I'm not very clear with the usage of stap-server/stap-server  that you 
> have described.
> This is what i understood:
> The staprun-server(stapgui-server/"lean" server) is to staprun what 
> the stap-client/stap-server is to stap.
Yes.
> 1. In a scenario where i create a script using stapgui, and i need to 
> execute it on a remote machine - i use stap-client to create the 
> module and use the staprun-server("lean" server) to execute the module.
Yes.
> 2. In a scenario where i create a script using stapgui, and i need to 
> execute on the same machine - i use stap and staprun instead of the 
> stap-client and staprun-server
Yes.
>
> The problem i have with this is that it creates a "hard-dependency", 
> in the sense , in scenario 1 if there is no stap-server the stapgui 
> cannot be used. I would like to use stapgui even if there is no 
> registered compile-server.
>
> The alternative would be to check if there is a registered 
> compile-server, if not use stap to compile on the  remote machine and 
> use the staprun-server for execution. This is how others had 
> interpreted you mail :).
Yes. The idea is that we can minimize the amount of duplicated 
functionality among our tools. However, if there is no stap-server 
available to remote compilation, then stapgui-server would then be 
forced to use stap to do the compilation.

Dave

Re: SystemTapGui usage scenarios.

[Frank Ch. Eigler]

Dave Brolley <brolley@redhat.com> writes:

> [...]  However, if there is no stap-server available to remote
> compilation, then stapgui-server would then be forced to use stap to
> do the compilation.

What if stap-client was taught to fallback to a local "stap" if it
can't find a server?

- FChE

Re: SystemTapGui usage scenarios.

[Dave Brolley]

Frank Ch. Eigler wrote:
> Dave Brolley <brolley@redhat.com> writes:
>
>   
>> [...]  However, if there is no stap-server available to remote
>> compilation, then stapgui-server would then be forced to use stap to
>> do the compilation.
>>     
>
> What if stap-client was taught to fallback to a local "stap" if it
> can't find a server?
>
>   
Probably not a bad idea on the client side. However, the comment above 
was meant to address the situation where stapgui needs to do a remote 
compile for remote execution on a system which does not match the 
stapgui host. In this case, the stapgui-server on the remote host would 
have to use stap to do the compile if a suitable stap-server is not 
available.

Dave

SystemTapGui usage scenarios.

[Anithra P Janakiraman]

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.