Revision as of 10:47, 9 March 2022

Approved VOs Policy

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

Introduction

GridPP is part of the UK National Grid Initiative. We are expected to support the work of related organisations outside of the LHC or high-energy physics. The GridPP Project Management Board (PMB) has agreed that 10% of GridPP's processing capability should be allocated for non-LHC work so that some CPU cycles are provided for the benefit of wider causes. This is a lower limit on what will be provided. VOs that access the Grid in this way way are referred to as Approved VOs. It is not mandatory for a grid site to enable the Approved VOs, but GridPP endorses and supports grid sites that do so. Up to 10% Tier-1 and 3% Tier-2 storage deployed at sites may be available for these approved VOs.

Note that this document only relates to GridPP Approved VOs. It does not restrict a site from supporting VOs outside the list of approved VOs.

Approved VOs Document

Approved VOs are formally listed in the Approved VOs document. The document shows the status of the Approved VOs, and it publishes the security records (VOMS records) that are needed to enable a VO at a site.

Nomination, acceptance, notification and removal

It is a prerequisite that any VO applying for Approved status must be present and correct in the EGI Operations Portal. The VO_Registration procedure describes how to register and validate a new VO for use on the EGI infrastructure, while the VO Deregistration procedure describes how to deregister a defunct VO. The EGI Operations Portal is used as the canonical source for the VOs security records.

Any prospective Approved VO is nominated, accepted, categorised or ejected by the PMB. Alternatively, a prospective Approved VO may be inducted or removed via a collaboration view (e.g. via discussion at Ops Meeting). There are several categories of Approved VO, e.g. Approved EGI VO, Approved Global VO, Approved Local VO and Other Approved VO. Decisions regarding the removal of support are made in a similar way. Prior to removal, there must be a study to check that there is no recent usage. The collaboration should discuss and decide on the data and storage implications prior to the removal of any VO.

The Core Team Member for Documentation (Steve Jones) and the Core Team Member for Wider VO Participation (name TBD) and the must be informed of any change. These will ensure that the appropriate documentation changes and broadcasts to site admins are made, using the “on-going management” process below.

On-going management

From time to time, a VO will require changes to its security records. This can happen if administrators find erroneous data for the VO within the Operations Portal; they would then raise a GGUS ticket against the VO. It also happens when, for example, a VO changes its VOMS server configuration, etc. VOs announce changes in various ways, but GridPP's minimum requirements are as follows:

• the VO manager must implement its changes in the Operations Portal, which is regarded as the canonical source of VO information.

• the VO manager must use a reliable communication channel to inform (at least) the Core Team Member for Documentation (Steve Jones) and Core Team Member for Wider VO Participation (name TBD) and of any changes made.

On receipt of such an alert, the Core Team Member for Documentation will update the Approved VOs document to contain the new information, using VomsSnooper. He will use the TB_SUPPORT list to broadcast an alert of the changes to site admins within GridPP, and send a message to the VO concerned.

It is the responsibility of the site admin to prioritise the changes required. Procedures for keeping the records straight vary from site to site, and include updating by hand (reading the Approved VOs document or the VOID cards), or the use of some tool such as VomsSnooper to update directly from the Operations Portal. Also, server reconfiguration is needed to ingest the new records, perhaps using YAIM etc. Admins should consult this table to check their current standing.

https://pprc.qmul.ac.uk/~walker/votable.html

In addition to reacting to VO alerts, Core Team Member for Documentation will scan the Operations Portal on a weekly basis with VomsSnooper to catch unannounced changes. If such changes occur, he will:

• Contact VO to inform them that unannounced changes are being made to their data and
• Follow the process above to update the Approved VOs and alert the GridPP site admins.