Page tree
Skip to end of metadata
Go to start of metadata

Document control

AreaEGI Federation Operations
Procedure status

FINAL

OwnerCatalin Condurache 
ApproversOperations Management Board
Approval status

APPROVED

Approved version and date

v1,  

Statement

The document describes the process of enabling the replication of CVMFS spaces across OSG and EGI 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




Table of contents

Overview

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

This procedure defines the steps for the replication of a VO space from OSG 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 representative (VOR): person who is responsible for initiating the replication process.
  • OSG CVMFS Manager (OSGM): person or team who is responsible for the operations of the CVMFS services for the OSG infrastructure
  • EGI CVMFS Manager (EGIM): person or team who is responsible for the operations of the CVMFS services for the EGI infrastructure

Requirements

VO can ask to replicate the CVMFS areas used in one of the two infrastructures if they have sites supporting the VO in both EGI and OSG. The sites should already support CVMFS.

Steps

  • Actions tagged VOR are the responsibility of the VO Representative.
  • Actions tagged OSGM are the responsibility of the OSG CVMFS Manager.
  • Actions tagged EGIM are the responsibility of the EGI CVMFS Manager.
ResponsibleActionPrerequisites, if any
1VORSubmit CVMFS replication request
The VOR opens a GGUS ticket specifying the name of the VO in EGI, if the VOR is not the VO Manager, the VO Manager should be notified by involving him in the ticket.

The ticket must specify the name of the repository hosted by the OSG CVMFS infrastructure that the VO wants to be replicated in EGI.

The VO 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

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 CVMFS


3EGIMOpen a ticket for every Stratum1 who should import the new VO 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 VO.

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 VO file system in the CVMFS infrastructure
The EGIM checks the correctness of the replica from OSG and the distribution of the files to the Stratum-1. Once the VO 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.