Cracow Grid Workshop Grid Software Installation Tools Forschungszentrum Karlsruhe GmbH, Germany Forschungszentrum Karlsruhe In der Helmholtz Gemeinschaft

Cracow Grid Workshop 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

Cracow Grid Workshop 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)

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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 software Useful for huge packages + Integrates well into the EDG MW +/- Installation tools depend on high level MW - User depends on ESM to support his software and version - ESM jobs conflict with user jobs - ESM is not a normal user

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop Alien/gLite packman ● Design goals ● Support the LHC Experiments ● Frequent releases ● Support individuals to install own software ● Steer job to site

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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/ / ” ● 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_.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

Cracow Grid Workshop GAIT Example job.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 job.jdl Executable = "job.sh"; StdOutput = "out"; StdError = "err"; InSandbox={"job.sh","GAIT.tgz"}; OutputSandbox = {"out","err"}; install_package sh source $INCLUDE_DIR/gait.sh.h function gait_install_package { SW_DIR=$1 cd $SW_DIR wget package tgz tar xzf package 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

Cracow Grid Workshop 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

Cracow Grid Workshop 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