xrootd in SRM and GLUE: a proposal

Introduction

This document has the following purposes:
  • to describe how the different SRM implementations manage the xrootd protocol;
  • to describe how the different storage systems publish xrootd to the information system;
  • to highlight some problems of the current situation;
  • to propose how to solve these problems.

How to get an xrootd TURL in an srmPrepareToGet and an srmPrepareToPut function

One of the arguments of the functions is a TTransferParameters structure, which contains an arrayOfTransferProtocols string array. Each protocol is therefore identified by a string (protocol identifier). The SRM will return to the client a TURL for the first supported protocol in the array. The following tables show the type of TURL returned by different SRM implementations for different protocol identifiers; entries in red are proposed for deprecation, entries in green are proposed for implementation and entries in black should not change.

CASTOR

Protocol identifier TURL syntax Actual TURL protocol Understood by ROOT
root castor://... rootd protocol yes
xroot root://... xrootd protocol yes

Support for the rootd protocol is a legacy feature and it is expected to be phased out some time in the future. As a consequence, root as protocol identifier will become unsupported.

Problem: the root identifier corresponds to a different access protocol in CASTOR and dCache.

Proposal: nothing should change in CASTOR.

dCache

Protocol identifier TURL syntax Actual TURL protocolSorted ascending Understood by ROOT
root (1) root://... xrootd protocol yes
xroot [x]root://... (2) xrootd protocol yes

(1) This value will not be deprecated until it is guaranteed that no clients critically depend on it.

(2) The TURL prefix can either be root or xroot. Arguments can be given in favour on one choice over the other, for example:

  • root: most used for historical reasons; coherent with the current CASTOR and dCache behaviour;
  • xroot: equal to the protocol identifier.
ROOT is perfectly compatible with both choices. Therefore, no recommendation is given and the choice is left to the SRM implementation.

Problem: the root identifier corresponds to a different access protocol in CASTOR and dCache.

Proposal: to use xroot rather than root as protocol identifier, as CASTOR and DPM do.

DPM

Protocol identifier TURL syntax Actual TURL protocol Understood by ROOT
xroot xroot://... xrootd protocol yes

Problem: none.

How to publish support for the xrootd protocol in the information system

GLUE 1.3 and the "WLCG Installed capacity" document

According to the GLUE 1.3 schema specification and the "WLCG Installed Capacity" document version 1.9, all Storage Elements must adhere to these prescriptions:
  • Access protocol. If xrootd is a supported access protocol, it MUST be published and the Type should be listed here; unfortunately there is no string for xrootd;
  • Control protocol. If an SE provides an "xroot door" it MUST publish a control protocol object for xrootd and MUST NOT do so otherwise. The Type MUST be xroot and the full control endpoint is of the form [x]root://....

Although it is not written anywere and is not compulsory by any means, it is desirable to use the same string for the access protocol type in GLUE and the protocol identifier in SRM. There are at least two arguments in favour:

  • it avoids the need to know which protocol identifier corresponds to which access protocol Type;
  • some SAM tests assume they are equal.

GLUE 2.0

In GLUE 2.0, the StorageAccessProtocol entity has a Type attribute, whose value for the xrootd protocol is xrootd. it is not mandatory to publish a given access protocol to make it discoverable. The concept of control protocol is not present and it is basically replaced by the StorageEndpoint.

There are not yet any WLCG-specific recommendations on how to use the GLUE 2.0 schema.

CASTOR

Access protocol type Actual access protocol
xroot xrootd protocol

Problem: CASTOR does not publish anything at all. An official CASTOR information provider is currently in development.

Proposal: to publish xroot as Type.

dCache

Access protocol type Actual access protocol
root (1) xrootd protocol
xroot xrootd protocol

(1) This value will not be deprecated until it is guaranteed that no clients critically depend on it.

Problem: the current value, root, is not acceptable for xrootd.

Proposal: to publish xroot as Type.

DPM

Access protocol type Actual access protocol
xroot xrootd protocol

Problem: none.

xroot or xrootd?

A point to be addressed is whether to use xroot or xrootd as protocol identifier. Some boundary conditions should be considered:
  1. in the GLUE 2.0 working group, xrootd was agreed as the official access protocol name, following the choice of the xrootd developers;
  2. the "WLCG Installed capacity" document says that the Type of the xrootd protocol as control protocol MUST be xroot, but says nothing about the xrootd protocol as access protocol;
  3. some SE implementations publish xrootd (the ALICE SEs) and some publish xroot (DPM).

To summarize, a protocol identifier is needed in four places:

  • as control protocol Type in GLUE 1.3;
  • as access protocol Type in GLUE 1.3;
  • as StorageAccessProtocol Type in GLUE 2.0;
  • as protocol identifier in SRM.

Proposal: to use everywhere xroot and amend the GLUE 2.0 specifications.

The advantages are:

  • it is consistent with the "WLCG Installed capacity" document;
  • it is still possible to amend the GLUE 2.0 specifications;
  • it does not require to know how the GLUE Type maps to the SRM identifier if they are different.

Conclusions and proposal

To summarize, the following proposal is made:
  • xroot MUST be a valid protocol identifier in SRM for the xrootd protocol. This requires a change only in dCache;
  • root SHOULD NOT be used as protocol identifier in SRM for the xrootd protocol. This would require a change only in dCache: however, it is agreed that it can wait until it has been verified that it will not break existing software;
  • TURLs for the xrtood protocol MUST begin by either root:// or xroot://. The choice is left to the SRM implementation. No change is required;
  • xroot MUST be used as protocol Type in the information system for the xrootd protocol. This requires changes in the information providers for CASTOR and dCache and an amendment of the GLUE 2.0 schema specifications. dCache MAY wait until xroot is supported as protocol identifier in SRM.

-- AndreaSciaba - 11-Mar-2010

Edit | Attach | Watch | Print version | History: r7 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2010-03-11 - AndreaSciaba
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback