Grid Software Installation Tools

1
Grid Software Installation Tools
Forschungszentrum Karlsruhe In der Helmholtz
Gemeinschaft
Ariel.Garcia_at_iwr.fzk.de
Marcus.Hardt_at_iwr.fzk.de Harald.Kornmayer_at_iwr.fzk.d
e Forschungszentrum Karlsruhe GmbH, Germany
2
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

3
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)

4
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

5
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

6
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
• gt depends on 15 site admins to install it
• - Obey to strict policies

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

8
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

9
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

10
TankSpark

• 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

11
TankSpark

• 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

12
Alien/gLite packman

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

13
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

14
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

15
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

16
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/ltsoftw.gt/ltrelgt
• 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_ltsoftwaregt.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

17
GAIT

• Example

18
GAIT

• Pro's and Con's
• - Not many packages yet
• gt 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

19
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
• TankSpark
• GAIT
• Check out available tools to simplify your
  deployment