DPM and ATLAS Space Tokens

So, here's the definitive guide to enabling space tokens for ATLAS:

1. Assign the token to atlas/Role=production using the dpm-reservespace command. (Example here.)
2. Create the directory where DDM will put the files, which is the normal path for ATLAS, plus the name of the spacetoken in lower case. e.g.


• dpns-mkdir /dpm/gla.scotgrid.ac.uk/home/atlas/atlasdatadisk


3. Now change group ownership of this directory to atlas/Role=production, chmod it to 775 and finally add two ACLs which will mean the entire tree will be writable by production roles:




• dpns-chgrp atlas/Role=production /dpm/gla.scotgrid.ac.uk/home/atlas/atlasdatadisk


• dpns-chmod 775 /dpm/gla.scotgrid.ac.uk/home/atlas/atlasdatadisk


• dpns-setacl -m d:g:atlas/Role=production:7,m:7 /dpm/gla.scotgrid.ac.uk/home/atlas/atlasdatadisk


• dpns-setacl -m g:atlas/Role=production:7,m:7 /dpm/gla.scotgrid.ac.uk/home/atlas/atlasdatadisk




4. Enable the space token publisher (this only needs to be done once - subsequent tokens are picked up automatically). Instructions here.
   

ATLAS Space Token Roles

Following a discussion with ATLAS people I've now clarified that SRMv2 writing will happen using the atlas/Role=production VOMS role.

Therefore sites should restrict access to the ATLASMCDISK and ATLASDATADISK space tokens to this role. To do this, release and then recreate the space reservation:

# dpm-releasespace --token_desc ATLASDATADISK
# dpm-reservespace --gspace 10T --lifetime Inf --group atlas/Role=production --token_desc ATLASDATADISK

Greig's python snippet to list spaces is very helpful.

DPM Storage Token Information Published

It was a bit fiddly, but with 4 fixes to Michel's script, Glasgow are publishing the space token information for ATLASDATADISK.

I documented the workarounds in the LCG Twiki.

WLCG Workshop

There's a lot on the agenda page, and Jamie's CHEP summary talk is a useful round up, but here are my highlights:

• GDB consider services necessary for WLCG operations to basically have been delivered, but not fully deployed (far less extensively tested and battle hardened). My own feeling is that in the integration and mutual interaction (e.g., VOMS and SRM v2.2) of all these services with WLCG production we've still a long way to go.
• In their pre-acceptance tests, the gLite-CE and the CREAM CE did about as well as one another. Given that CREAM has a simpler internal architecture and is more standards compliant it has been chosen over the gLite-CE (which is "no longer being developed"). It's anticipated that CREAM will be first delivered to production in the New Year, but that in total it's anticipated to take about a year from now before it's fully hardened, sites have experience in running it and the YAIM configuration is fully working - oh! just around data taking time ;-) However... this seems rather sensible to me to have settled on the one CE, rather than the unsatisfactory situation of having 2 on the go. Pity the poor folk who put effort into actually running gLite CE as a service!
• Operations: We still have trouble sharing knowledge. 2007 was the year of the grid blog, but only a fool would pretend that will solve all our problems. I proposed a wiki plugin, where articles less than a month old would be black on white, with the text gradually fading to paler shades of grey the longer the article was unrevised. When it reaches white the article is expired!
• SAM is the test framework for everyone. Experiments should publish their tests into SAM so that it's a one-stop-shop for sites' status.
  
• Monitoring: We look forward to a proper demo of the SAM/nagios framework at EGEE.
• SRM v2.2: Confusion still abounds. What spaces to ATLAS want at T2s? Not even they know yet...
• Dress Rehersals: Lots going on for every experiment. See their presentations for more details.
• Common Computing Readiness Challenge (CCRC): There's an urgent need to tests the whole of the Accelerator->T0->T1->T2 chain for all experiments before real data flows. This will probably happen in February (limited, because not everything will be ready) and in May (really, has to work!). I expect this to be quite a big deal for everyone, especially the May round.
  
• ATLAS Session: Good information on Production Dashboard, DDM dashboard and operations (with cool http queries).
  

Right, before the suntan gets washed off and all memory of antipodean adventure fades, better blog a bit about my vist to Melbourne Uni on the second week of the trip.

First Monday, it's VPAC. "Data Management and Storage in EGEE" is my talk.

VPAC is the Victorian Partnership for Advanced Computing. I'm giving much the same talk as I did at AUSGRID, but with some particle phyiscs at the beginning. This is partly to flesh things out, but mostly because the LHC is so cool it makes the storage and data management parts of the talk more interesting, having set the context for why we are doing what we're doing. This is my first talk pretending to be a particle physicist - remarkable what an afternoon browsing the Standard Model on wikipedia can produce ;-)

The audience are mostly coming from an HPC background, so they are more used to providing compute resources and fast interconnects, but now they have an interest in providing cross-site storage, rather and some dedicated disk hanging off their HPC. Oh, and they've heard about the grid.

Again, the scale of the EGEE project is generally appreciated - and by implication that the solutions we've adopted do scale. I'm specifically asked about why we ddn't use SRB. This is hard to give a definitive answer on as I don't know enough about SRB, however, the EGEE solution (usefully charactarised by Jens as component based) is that:

1. It allows poorly performing components to be replaced individually, e.g., the replacement of the RLS with the LFC.
   
2. It allows sites, whose storage is also serving local users and legacy applications, to layer an SRM interface on top of their storage, rather than have to implement a completely new system.
   
3. It makes it easier to deploy at a large number of sites, where agreements across the whole grid are often difficult to achieve.
   

In the discussion it also becomes clear that SRB doesn't offer any good methods of data localisation - there's no easy way to ensure that jobs at a site can access SRB data efficiently. There doesn't seem to be an SRB LAN access protocol, like rfio or dcap.

After the talk I discuss SRB a little more with David Bannon. He says that the SRB model of federations of storage is actually quite fragile and only seems to work if all the SRBs are running exactly the same release - so it's back to big bang upgrades to maintain.