MAN page from RedHat EL 3 lcg-ManageSoftware-2.0-4.noarch.rpm

lcg\-ManageSoftware

Section: Misc. Reference Manual Pages (l)
Updated: November 7, 2003
Index

NAME

: lcg-ManageSoftware provides a way to install, validate, remove and run an experiment software application on LCG-2

SYNOPSIS

lcg-ManageSoftware --action --vo <exp> --tag <the_tag_your_are_going_to_install/validate/remove> [--tar <tarball_or_list_of_tarballs> --SE <SEhost> --CE <CEhost> -S <software_name> -V <version> -N <number of tar> -R <Release number> --tag <customized_tag> --validate_scrip <customized_name_of_script_for_validate> --install_scrip <customized_name_of_script_for_install> --uninstall_scrip <customized_name_of_script_for_removal> --run_scrip <customized_name_of_script_for_run> --notify <e_mail>]

DESCRIPTION

lcg-ManageSoftware is a bash script to install, validate, remove or run the Application software on LCG. It relies on the current schema for Software Installation on LCG; it is based on the figure of the Experiment Software Manager, on the VO_<VO_NAME>_SW_DIR environment variable and on the publication of the flag on the Information System (IS). The flag is automaticaly converted in to the right format TAG = VO-<vo_name>-<flag> by the script and published through the lcg-ManageVOTag utility.
The TAG published on the IS shows different flavours depending on the status of the underlying process.
The possible status values for a given version of the Experiment Software are:
<TAG>-processing-install  ---> an installation process is going on
<TAG>-processing-remove   ---> a removal process is going on
<TAG>-processing-validate ---> a validation process is going on
<TAG>-aborted-install     ---> an installation process failed for some reason
<TAG>-aborted-remove      ---> an removal process failed for some reason
<TAG>-aborted-validate    ---> an validation process failed for some reason

<TAG>-to-be-validated    ---> the installation process ran successfully and now the software is ready to be validate

<TAG> ---> the usual TAG indicating the site is homologated for this version of software.

lcg-ManageSoftware doesn't know how to install (or remove or rather validate the software). It's up to the Experiment Software Manager (ESM) to provide the script which perform the wanted action. The tool just helps the ESM to setup the right environment (in terms of root experiment area and temporary installing directory), to replicate in the most economic way as possible huge amount of bundle of data (it allows for a reliable transfer, for a workaround of the OUTBOUND connectivity requirement, for the failure recovery of the transfer it self); it's also useful because it checks the status for other concurrent installing (or removing) jobs, it manages the Information System by adding or removing TAGs depending on the results of the underlying process.lcg-ManageSoftware allows in this way the possiblity to trace back - in real time - the status of each managing software process.Furthermore, depending on the value of the root experiment software area, it spawns (if installed) the "Tank and Spark" mechanism for software propagation in WNs which doesn't share disk area.
lcg-ManageSoftware allows also to manage installations upon AFS based disk servers; if "Tank and Spark" is installed (even if not running) and if a AFS principal is defined (through a configuration file), it calls a functionality that allows for the conversion of GSI credentials into AFS Kerberos tokens.

lcg-ManageSoftware is flexible enough to allow the ESM to decide whether install through tarball or just provide a script that perform the wanted action in a fully indipendent way.In the former case it's mandatory to include in the archive(s) the script to be used for the installation which is later on called by the framework it self.Currently supported archive formats are *.tar *.tar.gz and *.tgz and must be passed to the script through the option --tar followed by one or by the list of tarballs (including also the extensions). If there are more than one archive the list of name must be included between "'".

No name convention are adopted for tarballs, tags or scripts used to manage software; however if the ESM doesn't specify the name of the steering script through one of the options --validate_script or --install_script or --uninstall script the corresponding default values are taken in to account ("validate_sw" ,"install_sw", "uninstall_sw").If the script to be used is not present, it returns an error and doesn't start the process.For backward compatibility it's still kept the old possibility to define tarball names and/or tag to be published with the format:

with:
<S>=software name
<V>=version number
<R>=release number ("null" if not specified).

ARGUMENTS

The script is invoked passing the <action> to do. This parameter is mandatory and it can be chosen among --install , --validate , --run , --uninstall and --iv actions available.

An installation process is a job that put data in a permanent way into the filesystem of the WN.A validation process is a job that homologates the software installed in some previous step.A removal process is a process that remove data from the filesystem of the WN that has been previously installed and validated.

The --iv action means that, during the same job, first the installation and then the validation process are called.It's then mandatory to provide either the installation script and the validation script otherwise the ESM will run on error.

The following arguments have to be passed:

The <--vo> argument is the Virtual Organization the user belongs. It 's also mandatory

The <--tag> argument is the tag to be installed/removed/validated. The script will perform a sort of handshake by putting in the right format and flavour this argument. The option is not mandatory if you provide the -S and -V options.

The <--tar> argument is the tarball (or the list of tarballs to be downloaded from the GRID). If there are more than one tarball you have to put between single quote this list of tarballs. The tarballs must include the extension. This argument is not mandatory if you provide the -S and -V options or if you provide directly (on the input sandbox) the script to be used for driving the wanted process or, finally, if the tarball.list file (old possibility still supported) is in the input sandbox.

The <--notify> argument is the e-mail address of the ESM. It's optional but quite useful in case the site supports Tank&Spark. The service for software propagation, at the very end of the propagation process will e-mail the ESM with a summary of the process it self.

The option --install_script allows the user to supply a different name (than the default one, install_sw) for the script to be used for installing software.

The option --validate_script allows the user to supply a different name (than the default one, validate_sw) for the script to be used for validating software.

The option --uninstall_script allows the user to supply a different name (than the default one, uninstall_sw) for the script to be used for removing software.

The option --run_script allows the user to supply a different name (than the default one, run_sw) for the script to be used for running software.

The <--SE> options is the Storage Element from where the user fetchs the tarballs with the experiment software. If not provided, the tool will use the default Storage Element from the environment variable $VO_${EXP}_DEFAULT_SE and even if this variable is not defined will use edg-brokerinfo to retrieve the information.

The <--CE> options represents the name of the Computing Element where the Software Manager will install the software and publish the new TAG. This option becomes mandatory if the job is submitted with -r option due to the fact that the tool retrieve informations of the CE through the BrokerInfo.
The <-S> ,a short descriptive string for the name of the software.

The <-V>, a string identifying the version of the software.

The <-R> , a string identifying the number of release of the software. The default is an empty string.

The last three option are used to build an univocally identifying string of the software (the TAG) if no external tag is passed to the script through the --tag option.

AUTHOR

support-EIS on behalf of Grid Deployment Group (support-eisAATTcern.ch)

This document was created byman2html,using the manual pages.