Document control

AreaEGI Federation Operations
Procedure status

UNDER REVIEW

OwnerCatalin Condurache 
ApproversOperations Management Board
Approval status

APPROVED

Approved version and date

v2  

Statement

The document describes the process of enabling the replication of CVMFS spaces across EGI and other partner collaboration CVMFS infrastructures

Next procedure reviewupon request

Procedure reviews

The following table is updated after every review of this procedure.

DateReview bySummary of resultsFollow-up actions / Comments

 

Alessandro Paolini copy from PROC20_Support_for_CVMFS_replication_across_the_EGI_and_OSG_CVMFS_services in EGI Wiki

 

Alessandro Paolini updated the GGUS SU name from CVMFS to Software and Data Distribution (CVMFS)

 

Catalin Condurache expanding the scope of procedure to all partner collaborations; removed the tie to a specific VOReplication of a CVMFS repo is not necessarily related to a VO, but rather to a community (that is yet to be organised as a VO)

Table of contents

Overview

The document describes the process of enabling the replication of CVMFS spaces across EGI and other partner collaboration CVMFS infrastructures. The aim of this procedure is to ensure that the CVMFS replication addresses real use cases and that the VO (or the community) managing the CVMFS area is supported by resource centres both in EGI and partner collaboration.

This procedure defines the steps for the replication of a CVMFS space from a partner collaboration infrastructure to EGI.

Definitions

Please refer to the EGI Glossary for the definitions of the terms used in this procedure.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Entities involved in the procedure

  • VO (community) representative (VOR): person who is responsible for initiating the replication process.
  • External CVMFS Manager (EXTM): person or team who is responsible for the operations of the CVMFS services for the partner collaboration infrastructure
  • EGI CVMFS Manager (EGIM): person or team who is responsible for the operations of the CVMFS services for the EGI infrastructure

Requirements

VO (or community) can ask to replicate the CVMFS areas used in one of the two infrastructures if they have sites supporting the VO (or community) in both EGI and partner collaboration. The sites should already support CVMFS.

Steps

  • Actions tagged VOR are the responsibility of the VO (or community) Representative.
  • Actions tagged EXTM are the responsibility of the partner collaboration CVMFS Manager.
  • Actions tagged EGIM are the responsibility of the EGI CVMFS Manager.
#ResponsibleActionPrerequisites, if any / Comments
1VORSubmit CVMFS replication request
The VOR opens a GGUS ticket specifying the name of the VO (or community) in EGI, if the VOR is not the VO Manager (or community representative), the VO Manager should be notified by involving him in the ticket.

The ticket must specify the name of the repository hosted by the partner collaboration CVMFS infrastructure that the VO (or the community) wants to be replicated in EGI.

The VO (or community) must be supported by more than one site in EGI, the sites should already support CVMFS in production.

- ticket assigned to Operations

2OperationsValidate the request
The EGI Operations team will verify that the request satisfy the prerequisites:
  • VO is in production
  • VO Manager has been correctly involved in the ticket
  • VO is supported by more than one EGI production Resource Centres

If a VO is not active to support the request, the EGI Operations team needs to find evidence and be satisfied that there is a community to make use of the the replicated CVMFS repository.

The outcome of the validation must be reported in the ticket opened in Step#1. If the request is valid the GGUS ticket must be assigned to Software and Data Distribution (CVMFS)

Replication of a CVMFS repository is not necessarily tied to existence of a VO, but a research/scientific community that needs access to that repository
3EGIMOpen a ticket for every Stratum1 who should import the new CVMFS space
The EGIM opens a GGUS ticket to the EGI sites hosting a CVMFS Stratum-1 that should import the file system from the new repository.

If the contact is done by email, EGIM must record in the ticket opened on Step 1 that the emails have been sent (and to which sites they have been sent), and also record that sites replied.


4EGIMConfirm the availability of the CVMFS repository in the CVMFS infrastructure
The EGIM checks the correctness of the replica from the partner collaboration infrastructure and the distribution of the files to the Stratum-1. Once the repository files are available in the Stratum-1, the EGIM reports the successful conclusion of the procedure and closes the ticket opened in Step#1. The procedure concludes here.

5VOR

This is an additional step, to be applied only when needed.


If the sites supporting the VO have not been configured with standard cvmfs installations that support automounting all opensciencegrid.org repositories (i.e. cvmfs-2.1.19 with cvmfs-keys-1.5, or later cvmfs release) then they may not be able to access the new repository. The VO should test the sites and submit GGUS tickets for those that cannot access the repository.