Client Discussion

Discussion Material

Elements of the Game:

• lcg-utils
• lcg-infosys
• glite-clients and glite-service discovery
• GFAL and glite-io; xrootd

Meeting Notes (Akos, Peter, Gavin)

lcg-utils and glite-*-cli would be merged into a single(?) CLI package. Discarding gLite I/O clients (which would be phased out) we still have a few components to merge.

we have to re-factor these components into common components and dedicated ones while keeping some wrappers for backward-compatibility. also something to be started soon.

As far as I understood the new CLI package will be "branded" as gLite, but providing backward compatibility wrapper scripts for the current lcg-utils commands.

the gLite side of the picture:

• transfer-url-copy: could replace EDG url copy it has all the glite equivalents for the edg gridftp client tools. it would be properly supported.

• srm-cli: SRMv1 support; overlap with lcg-utils this component is a candidate to be the only SRM cli interface for lcg. it is currently being extended to have srmv2 support

• transfer-cli: FTS client
• catalog-cli: when LFC has a WS frontend, it can be used
• delegation-cli: WS based delegation for FTS
• ui: Parrot based "virtual file system" in userspace only with libc pre-load; we should have a look, but keep separate
• io-client: phased out after the review, so won't be merged, but kept as-is separately
• hydra-cli: en/decryption library can be moved to the new CLI package, rest is using gLite I/O (see above)
• service-discovery-cli: there is an overlap with LCG info utils, should have a look, since it is able to cope with R-GMA too the service discovery is an interesting candidate to be used with/instead of the lcg-infosys

Review the functionality needed by gLite-url-copy library and check whether lcg-utils / GFAL does it all.

Review additional features of lcg-utils (e.g. the wrapper around asynch gobus calls) to see how we could use it in glite-url-copy.

xrootd support

A simple setup should satisfy the VOs having a need for xrootd:

• The xrootd servers can be set up as VO servers so that it is in the VO domain
• All data on these servers are readable by the whole VO

Discussion Preparation

It seems that all lcg- command line tools are to be rebranded as glite- tools. We need to see which ones can simply be renamed and which ones should be merged or replaced by other glite command liners.

Details

These are the client components i can think of off the top of my head

• lcg-utils suite, see for example http://www.gridpp.ac.uk/deployment/users/datamanagement/howtolcg.html
• lcg infosys
• lfc- clients
• glite service discovery glite-sd-query
• glite-url-copy
• glite-gridftp-*
• glite-get glite-put and glite-rm
• glite-catalog-* clients
• glite-job-*

there must be many more. To discuss

• Which ones to keep, which ones to drop
• Common set of options
• Common way of configuration ( service discovery? )
• Backward compatibility and migration

Names

• keep existing names for a while, running them in parallel (/opt/glite /opt/edg /opt/lcg)
• it would be desirable to have everything eventually under the same tree and namespace (1st April?) => migrating to =/opt/glite
• WMS may be lagging behind

Libraries

• There is GFAL
• On top of it there is an lcg-util library
• And there are CLIs for these
• Also having been asked for non-c but also perl, ... --> swig it
• If there is a WSDL it is possible to do a native solution

Q: How long will RLS still be supported?

A: It was supposed to stop at end of 2005, but an extension of 6 months was asked by CMS and ATLAS

LCG Infosys and sd-query

• infosys is much more than service discovery
• it is a set of command line tools

Q: Where is infosys used?

A: in scripts, also for SD-like things..

• SD is not tied to a backend but is limited in scope by design

--> understand where infosys is being used, how much of this usage may be covered by SD --> build SD into cli tools

• for reading infosys data and publishing data it would be good to have a generic solution not tied to a backend
• patrick fuhrmann in desy has a student working on publishing SRM info into bdii and rgma

Basic Building Blocks

externals:

• dcache clients (gsidcap, dcap)
• globus rls
• vdt security libs
• vdt gt4
• vdt gridftp v2
• gridsite
• openldap
• vdt myproxy

semi-external

• vdt bdii
• vdt lfc
• vdt dpm
• vdt fts

internals:

• basic library
  • service discovery
  • SRM
  • gridftp
  • rfio-common
  • encryption-decryption
• catalog library
  • LFC
  • fireman
  • RLS
• keystore
• posix i/o in GFAL
• ACL mgmt in GFAL
• namespace mgmt in GFAL
• FTS
• job submission
• monitoring of stderr/stdout
• job monitoring
  • state
  • metrics in running state

We need to have consistent error messages and consistent CLI usage

Actions

• Akos : follow up infosys / sd with patricia and laurence
• Jean-Philippe, Gavin: Follow up 'basic library' design
• Laurence: start Developer Guide
• Patricia + Akos : CLI usage template
• Ricardo + Antonio : Error message schematics, error codes returned by CLI

-- PeterKunszt - 08 Nov 2005