Re: [RFC] Framework for easy distribution of SystemTap scripts (V4)

[Anithra P Janakiraman <anithra at linux dot vnet dot ibm dot com>]

On 04/14/2010 02:26 AM, Frank Ch. Eigler wrote:
> Hi -
>
>
> > > Why *not* install it?  How are people supposed to get a hold of your
> > > script if it doesn't get installed?
> >
> > This script will be used by a very select set of users - say admins who
> > wish to debug a customer machine, don't think it would be right to
> > install it as part of the systemtap/systemtap-runtime rpms as it is not
> > going to be used by the 'regular' stap user. It can be obtained from the
> > source.
>
> Well, if you are targeting this to such a specific subset of users,
> then perhaps there is little need to include the script within the
> systemtap source tree.  It could be as easily downloaded from the wiki
> for example, no?

That should be ok too..
> > > (There still appears some ps -ef | grepping in the new version; probably
> > > all of that is unnecessary, if you save child pids properly.)
> >
> > With the -start option, staprun executes in the background while the
> > script exits. To stop users need to run the package with -stop, it would
> > not be possible to store the child pids in this scenario.
>
> (If you used the normal flight-recorder mode startup/shutdown options,
> the pids wouldn't be needed, since the module name is used as the
> key.)

We are assuming that SystemTap might not be installed on the machine 
where the package will be executed. We package the bare minimal 
(staprun/stapio) needed to run the module. The initscripts might not be 
available.

> > [...]
> > > To have a separate configuration file for this only, you'd need to
> > > argue why some options have to be treated differently from others.
> >
> > The problem here is that we are not aware of the options or the no of
> > options before hand. This would vary from script to script.
>
> I guess the help text is not specific as to what these option strings
> actually do.  They appear to be made available to the hand-coded
> template file as shell variables, which happens to use $time.  How
> else are these options conceivably used?  Not staprun module-options;
> not apparently post-processing-script environment variables.

The config file and parameters should have been passed to the 
post-processing script. I had completely overlooked that. Thanks for 
pointing it out. Attached the modified template.
The time options is used by the wrapper/template script and the rest are 
passed to the post-processing script.

The help text would be specific to what the options strings do. For eg:
if the config file had  a default:
ipaddress=127.0.0.1

The help text would contain:
ipaddress=[ip] ip is a standard IPv4 address. The output will be 	
	       filtered for this address

The resulting package would have the following --help

Options:
           options explained
Parameters:
    time=[x]   x is in minutes. Runs the script for x minutes. valid	
		for --run(-r) o --start(-s) or --all(-a) options only
    ipaddress=[ip] ip is a standard IPv4 address. The output will be
	      filtered for this address


If an ipaddress is specified at the command line when executing the 
module it would be passed to the post-processing script.

Thanks,
Anithra

Attachment: distributionframework_v4.patch
Description: Text document