Cracow Grid Workshop 2004 - [email protected]@iwr.fzk.de Grid Software Installation Tools [email protected] [email protected]

Cracow Grid Workshop 2004 - [email protected]

Grid Software Installation Tools

[email protected]

[email protected]

[email protected]

Forschungszentrum Karlsruhe GmbH, Germany

Forschungszentrum KarlsruheIn der Helmholtz Gemeinschaft


Introduction

● The issue of managing software packages is not new

● Many approaches exist:● RPM (Redhat, SuSE, Mandrake, ...), Portage (Gentoo), Ports

collection (FreeBSD, NetBSD, OpenBSD, ...), Pacman (NMI), dpkg/APT (Debian)

● These approaches (and usually grid middleware) often require root privileges for installation

● Applications can usually be installed by any User


Use cases in Grid Environments

● Middleware Development:● Install as root● Homogenous Testbed (all sites at the same versions)● Quick rollout procedure● Central control

● HEP Experiments:● Non root installation● Large amounts of software (up to 6GB per

Experiment)● Installation per site● Central control

● Generic Grid User:● Independence of central instances● Independence of organizational boundaries● Portability (as few dependencies as possible)


X# Deployment

● Design goals● Focused on middleware installation● Homogenous development environment

● Central control over software that is installed● Defined deployment procedures

● Release Management● definition● rollback● production TB – development TB

● Build on top of existing technologies


X# Deployment

● How it works● Packages are in RPM format

● Packages provided via autobuild● Distributed via webserver

● Local ConFiGuration tool (LCFG)● All sites use LCFG to install/configure

● Common part of testbed configuration in a common directory in CVS

● CVS branches: Production TB / Development TB● Rollout:

● New version (CVS-tag) announced to site admins● Site admins run update tools

● Install release● Release version is published in Information

Catalogue


X# Deployment

● Pro's and Con's+ centrally managable

+/- LCFG

+ Rollout time est. 1d (15+ sites!)

+ Proven to work in CrossGrid

- User, Developer depends on central instances- User must provide RPM packages

=> depends on 15 site admins to install it

- Obey to strict policies


LCG ESM Tools (LHC Experiment Software Management

Tools)

● Designed to fit LHC Experiments needs:● Experiment Software Managers (ESM) per VO

● Package/deplay/certify/support the Software● Manage dependencies <=> Local site admins● Are independent from other experiments

● Installation per site● Published installed versions in Information Catalogue● Steer Job to software

● Central control over which software is installed


LCG ESM Tools

● How it works● Initial installation

● New VO per Experiment for software management● only ESMs can write to VO directory● For deployment of VO packages

● Installing a new Software package:● ESM

● packages the software● replicates install package to SEs● steers job to site for

● installation/verification● tagging a site as supporting the software in Info

Catalogue

● User● Specifies the required software in .jdl to steer job● runs LCG tool to ensure SW installation on his WN● runs his job


LCG ESM Tools

● Pro's and Con's+ Out in the wild and being used (est 70 sites 800

pkgs)Must scale well

+ centrally managable

+ User can steer job to softwareUseful for huge packages

+ Integrates well into the EDG MW

+/- Installation tools depend on high level MW

- User depends onESM to support his software and version

- ESM jobs conflict with user jobs

- ESM is not a normal user


Tank&Spark

● Designed to improve LCG-ESM shortcomings:● Support VOMS● Avoid NFS related problems● Avoid ESM jobs in the queue with user jobs● Automated update of the whole grid

● How it works?● Tank daemon (webservice) is running on the CEs● Sparks clients are running on the Wns

● Clients poll CEs for orders● Clients rsync software from SE (put in place by the ESM, as

before)● Installation status is kept in MySQL-DB by Tank daemon● Available software is published in Information Catalogue


Tank&Spark

● Pro's and Con's+ centrally Manageable

+ Scalability proven to 1000 nodes per site

+/- Tool depends on high level MW● Optimized for keeping network load low

- User still depends on ● software and version specified by ESM / Experiment● Newest EDG/LCG middleware

● To be deployed with LCG-2.4


Alien/gLite packman

● Design goals● Support the LHC Experiments● Frequent releases● Support individuals to install own software● Steer job to site


Alien/gLite packman● How it works

● ESM Role present as well● User can also do this● Packaging / define dependencies in a metadata

catalogue / write preinstall, prerun scripts● One PackMan per site● Shared filesystem holds installable packages

(alien FC)● Required packages are specified in .jdl● WN triggers installation of required packages by

contacting PackMan on CE● PackMan

● installs in shared dir● Returns a list of environment files for sourcing

● WN executes the job


Alien/gLite packman

● Pro's and Con's+ Aims at supporting individual users

- Not yet deployed on a broad scale

(=Not much known about it)

-/+ User depends on a high level middleware

- Depends on shared filesystem


GAIT (Grid Application Installation Tool)

● Design goals● Support individual users● Ease of use● Minimal dependencies

● On site admins● On installed software● On the underlying unix

● Don't waste resources● Don't install twice● Don't stay installed forever


GAIT● How it works

● Packager extends install_template.sh script to● define an install function to software● define a check function to verify software installation● define an optional function run a testcase on the software

● This script● Check in /opt, all homedirs, /tmp for

“GAIT/<softw.>/<rel>”● If not found, try installation own homedir and /tmp● If found it touches the installation for keeping it installed

● User● ships install_*.sh with his job● sources install_<software>.sh, which

● makes sure the software is installed● sets up environment variables properly

● runs his job● Unused software can be expired by user or admin


GAIT Examplejob.sh

#deploy GAIT

tar xzf GAIT.tgz #can b preinstalled

source GAIT/scripts/install_[..].sh

echo $GAIT_INSTALLDIR

echo $PATH

echo $LD_LIBRARY_PATH

#run the software

software-1.2-3

job.jdl

Executable = "job.sh";

StdOutput = "out";

StdError = "err";

InSandbox={"job.sh","GAIT.tgz"};

OutputSandbox = {"out","err"};

install_package-1.2-3.sh

source $INCLUDE_DIR/gait.sh.h

function gait_install_package {

SW_DIR=$1

cd $SW_DIR

wget package-1.2-3.tgz

tar xzf package-1.2-3.tgz

}

function gait_check_installation {

SW_DIR=$1

test -e $SW_DIR/executable || -1

# TODO: check md5 hashs of files

}

function gait_run_testcase{optional}

gait_run <package> <version>


GAIT

● Pro's and Con's- Not many packages yet

=> Prototype for dynamic deployment of userspace software on the grid

+ No dependencies on● Other Software (only plain unix-tools)● Site admins● Software Managers● Not even a grid

+ Only little impact on user job

+ Easily interfaces to higher level tools


Conclusions

● LCG-Experiment users are well supported● MW deployment defined in X# Procedures● Individual users are not well supported yet● Three new tools are just available

● Packman● Tank&Spark● GAIT

● Check out available tools to simplify your deployment

Documents

Cracow Grid Workshop 2004 - [email protected]@iwr.fzk.de Grid Software Installation Tools [email protected] [email protected]