SpaceTokens

Questions from Shawn

Hi Everyone,

At AGLT2 we have setup SRM V2.2 compliant spaces ATLASMCDISK,
ATLASDATADISK, ATLASENDUSERDISK and ATLASGROUPDISK. 

We are still using AGLT2_SRM (SRM V2.2 without space tokens) for all
production because of possible issues with various parts of the
production system supporting space tokens.  

Here is my understanding of things along with some questions.  Please
correct my mis-impressions.

A "space token" is a 6 digit number representing a storage
"contract"(size, lifetime, VO/role privilege).   Within ATLAS we have
"names" representing types of storage (as above).   The space token
should be created by the site's storage administrator.  For example, in
dCache this means that the space token for ATLASMCDISK will be
associated with the corresponding pools and directory setup for this
storage.   Also for dCache there is a way to "alias" the name for the
actual space token.  So an admin can configure a space token (605133)
and set ATLASMCDISK as a name for this (like DNS for a network
address?).  

For site's using  space tokens the ToA entry should explicitly call out
the "name" attached to the space token (e.g., ATLASMCDISK). 

Site's apparently need to publish (via GIP?) their storage and space
token info because some clients query this.

OK...now for my main questions:

1) For the space tokens Tier-2's are supposed to provide (see list at
top)
	a) ATLAS should be the only supported VO? 
	b) Should the "size" associated with each space-token be the
total size of the storage area setup for this purpose? (or should we
limit it to something less?)
	c) What is the "lifetime" we should use for the 4 tokens
(infinite) ?
	d) For the 4 tokens which "VOMS" roles should have which
privileges (read, write, delete)?

2) How should we configure dCache to "alias" the space token name? (An
example would be nice)
3) Can the various client tools directly utilize the "name" (as opposed
to the space token number)?
4) Can someone provide details of configuring GIP to publish the storage
information?

5) What is the status of PANDAMOVER, Pilots and (in general) the
production system regarding supporting space-token storage? (We really
want to transfer our production to our new storage locations because
AGLT2_SRM utilizes worker nodes for its pools and they don't serve files
well when running jobs).

6) Are there any tools within ATLAS which support implementing storage
"policies"?  Any recommended policies?

Thanks for any clarifications or examples.   It would be really useful
to have a web page that Tier-2's can go to for this storage migration to
space-tokens that would summarize all the steps and choices.

Shawn

Here is a US ATLAS Tier-2 table for SRM V2.2 compliant areas we must support

An example <site_domain> is aglt2.org and and example <site> is AGLT2.

References

• https://twiki.cern.ch/twiki/bin/view/Atlas/SpaceTokens

-- RobertGardner - 29 Apr 2008