Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

CVMFS Task Force

From EGIWiki
Revision as of 11:03, 26 July 2013 by Krakow (talk | contribs)
Jump to navigation Jump to search
Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security



Coordinator: Catalin Condurache/NGI_UK

Meetings page: Agendas

Mailing list: cvmfs-tf (at) mailman.egi.eu

Members:

  • NGIs: NGI FI, NGI HR, NGI IBERGRID, OSG, NGI ZA
  • MPI VT
  • VOs: VLEMED VO,

Introduction

NGI Status

NGI Status
NGI Ibergrid IBERGRID is already using CVMFS stratum 0 deployed at RAL as a service
NGI_ZA We were planning to deploy a stratum 0 in South Africa for VO sagrid applications, as well as those in use in other sub-Saharan countries.
NGI HR We are running CVMFS for our regional VO.
NGI FI we are one of the non-WLCG organizations running cvmfs.
OSG We recently implemented a CVMFS based service for the OSG. Our intended use case is for our virtual organizations and software

group to distribute their content by this mechanism. Our design is quite simple, we allow a very few people write access and everyone read access. We are actively adding resources with access enabled, wide adoption being the goal.

VO status

  • (1) is your community already familiar with CVMFS and is CVMFS already used in some form to support production activities?
  • (2) are you interested in trying CVMFS?
VO Status
VLEMED VO (1) used in some form to support production activities?

we were not until this email, but we asked around. The Dutch NGI is taking action already for non HEP users. we look forward to their findings.

(2) yes.

Johan Montagnat (1) No, we were not aware of this tool before.

(2) There is a clear need for easily deploying software packages grid-wise in the LS community. The existing solution of populating VO software space per site is often considered tedious, and leading to incoherent state when software cannot be installed on some sites due to installation job issues. So an alternative and global scale solution would be welcome. We would need to know a bit more on CVMFS though. From the slides shown, it is not clear how the software registered on the central CVMFS root directory is accessible from the sites / worker nodes in particular. (Is the CVMFS root mounted from all worker nodes? What is the performance impact of accessing to this remote software?).

Objectives

Milestones

Actions

Results