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.


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

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


  • 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


  • 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


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


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


  • 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


  • 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

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2005-11-11 - unknown
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback