NorduGrid plans and questions for gLite Marko Niinimaki, NorduGrid 3 rd EGEE meeting Athens, April 2005.

Finished ROME jobs

The interoperability scene: common protocols to make ARC – gLite FireMan connectivity. The “improvements” scene: enable searching by file attributes and metadata. Motivation: job submissions, data transfers etc. are handled already by both gLite, ARC, Grid3.. (job submission language may even eventually be the same). ARC uses RLS as a simple physical-logical filename mapper, users are unhappy: AA*, query language, performance*, no hierarchy*. using a “common” catalog-SE interface would make future integration easier for developers and prevent re-inventing the wheel. Plans

Does this make sense? Are there resources (manpower) to include this in the schedule? (From NorduGrid side yes) If yes, how to proceed (following slides) Questions

gLite FireMan gLite i/o storage soap over http/g rfio db clients FireMan architecture

FireMan/glite io client examples > voms-proxy-info VO : EGEE Valid from : Mar 7 12:36: GMT Valid to : Mar 8 00:36: GMT > glite-catalog-ls -l /tmp... dpdrwlxgspdrwlxgspdrwlxgs :37:15 /tmp/krzychu -pdrwlxgs :00:00 /tmp/la_vispa_teresa... > glite-catalog-mkdir /tmp/markoniinimaki > glite-catelog-rmdir /tmp/markoniinimaki

FireMan/glite io client examples (cont) > glite-put /etc/issue /tmp/markoniinimaki/mytest [glite_put] Total 0.00 MB |====================| % [0.0 Mb/s] Transfer Completed: LFN : /tmp/markoniinimaki/mytest GUID : 004d9388-4d47-122c-ad5e-808d2561beef SURL : srm://gridftp05.cern.ch:8443/srm/managerV1?SFN=/castor/cern.ch/user/g/gprodu ct/EGEETEST/SE/tmp/markoniinimaki/mytest Data Written [bytes] : 42 Eff.Transfer Rate[Mb/s] : > glite-catalog-find -name markoniinimaki /tmp > glite-catelog-setreplica /tmp/markoniinimaki/mytest > glite-catalog-getreplica /tmp/markoniinimaki/mytest srm://gridftp05.cern.ch:8443/srm/managerV1?SFN=/castor/cern.ch/user/g/gprodu ct/EGEETEST/SE/tmp/markoniinimaki/mytest

Part of ARC http/s/g data suite (other parts incl. data move) SSE is only part of full infrastructure and must be complemented with Data Indexing Services (IS). SSE has no internal structure for storing data units (files). Files are identified by their identity used in IS (Logical File Name, GUID, Logical Path, etc.) All operations on data units (creation, replication, deletion of replica, etc.) are done on request of the client through SSE. Access to data units on SSE is based on the identity of the client and uses GACL. SSE implements https/g protocols for data transfer. SSE can register stored files at Globus Replica Catalog (RC) and Replica Location System (RLS) indexing services. About SSE (

RLS (IS) ARC “Smart SE” storage db clients ARC SSE-RLS architecture

ARC SSE-RLS examples The SE in pcephc23 reports to RLS in grid.uio.no > ngcopy file:///etc/issue "se://pcephc23.cern.ch/se?foo" > ngls rls://grid.uio.no foo mytest > ngcopy rls://grid.uio.no/foo file:///tmp/foofile:///tmp/foo Normal RLS attribute searches can be applied, > globus-rls-cli attribute search size lfn '>' string 500 rls://grid.uio.no

Integration layer I simply do not know where it could be. ARC SSE emulates rfio (NG developers do not like this idea). SSE could either use part of glite-io which is responsible for talking to Fireman. Or Fireman interface could be used directly by SSE. [Unfortunately I wasn't able to make FireMan talk to anything else than gLite i/o].

The improvement part Boolean searches involving meta data, like: list all files owned by X, smaller than 2 GB, physically available in an SE whose name contains “uio.no”. Does the data that FireMan stores in db incluse such attributes? Can FireMan API (WSDL) be expanded to include such operations?

For completeness' sake.. Generated from manager/https/se/file_soap.h?rev=1.12;content-type=text%2Fplain <definitions name="ARCStorageElement" <schema targetNamespace=" xmlns:SOAP-ENV=" xmlns:SOAP-ENC=" xmlns:xsi=" xmlns:xsd=" xmlns:ns=" xmlns=" Manipulate access rules for named content

.. Add new content(file) Update metadata of content Search for named content and provide metadata Manipulate access rules for named content Remove contant and unregister it