CVMFS Use Cases for GridPP

Introduction

This page is for outlining use cases for deploying software with CVMFS with GridPP. It is very much a working draft and input from interested parties is very much welcome, either directly on this page or via the discussion page.

Definitions

Entities

• Virtual Organisation (VO): a group of GridPP users with similar scientific goals and requirements. The organisational unit for grid activities. See, for example, this EGI definition;
• Software bundle: (for want of a better term...) a tarball containing the scripts, libraries, executables, etc. to be run on the grid;
• CVMFS repository (repo): a subdirectory within /cvmfs/ unpacked software bundles to be run on the grid.

Actors

• VO member: a GridPP user who belongs to the specified VO with user security permissions as defined by the VO's security policy;
• VO administrator: a VO member who also has administrator security permissions for the VO;
• CVFMS administrator: a GridPP user who has administrator security permissions for the CVMFS RAL Stratum-1 (i.e. /cvmfs/);
• Site administrator: a GridPP user who has administrator security permissions for a given GridPP Tier-2 site (i.e. where the CVMFS software will be running).

Use Cases

• Create a new base CVMFS repository (repo) for a VO.
• Create a new sub-repo for a VO for all VO members.
• Create a new sub-repo for a VO member.
• Upload a software bundle to a VO member's sub-repo.
• Delete a software bundle from a VO member's sub-repo.
• Delete a VO member's sub-repo.

VO-specific Use Cases

LondonGrid

• Delete all of a VO member's sub-repos after the VO member has left the VO.

Useful links

• A quick guide to CVMFS.