Dynamic Megatable

Further agreements

General

• GlueSALocalID does not have any imposed format. The only restriction is that this identifier must be unique within a site.
• GlueSA represents a Storage Area that does not overlap with any other Storage Area at a site.
• A Storage Area can be shared among VOs. In this case only one GlueSA describes it. Such GlueSA has many GlueAccessControlBaseRules, one associated with each VO/FQAN that has access to the GlueSA.
• A Storage Area can have one or more VOInfo objects associated to it. Such VOInfo objects may or may not publish an associated TAG (i.e. the VOInfoTag is optional). The VOInfo object can be used to only publish the path associated to a VO for the Storage Area associated to that VOInfo object.
• A GlueSA can be published for space that is unreserved. In this case, the GlueSATotalOnlineSize will report the total space available (hmmm.... I am not sure here. I think that for consistency will still need to use the GlueSAReservedOnlineSize to publish the configured unreserved space. Could you please comment?)
• It was agreed not to use summary GlueSAs which do not correspond to any physical instance of a space (GlueSACapability: usage=megatable).
• It was agreed that GlueSAReservedOnlineSize must be equal to the space configured to create a given Storage Area. GlueSATotalOnlineSize must be equal to the total space for a given SA excluding broken or unavailable disk servers. GlueSAUsedOnlineSize is the space occupied by pinned files. GlueSAFreeOnlineSize=!GlueSATotalOnlineSize - GlueSAUsedOnlineSize
• Flavia will update the Glue v1.3 example published on the GSSD pages to reflect the current proposal for publishing spaces.

CASTOR

• Jens will make sure that the proposal makes sense for CASTOR and come back with an answer by June 24th.

dCache

• Paul Millar will investigate with the dCache developers team to see if it is possible to provide the information about the space occupied by pinned files only.
• Paul and Ron will come up with a proposal for a minimal set of Keys needed for the Capability field in GlueSA.
• Paul will verify with the dCache developers team that the proposal makes sense for dCache and come back with an answer by June 24th.

DPM

• M. Jouvin will check the current GIP and let us know of possible problems implementing the current proposal.
• Unreserved space can be covered by GlueSA with GlueSA associated VOInfo objects with no tag and a path per VO/FQAN.

StoRM

• StoRM already implements this proposal. The StoRM team will verify that the path published by StoRM in the VOInfo object at the moment is conform with this proposal.

-- FlaviaDonno - 23 Jun 2008