Skip to content

Remove gRPC client code from CTA Frontend

Problem to solve

The CTA Frontend cta-admin tapefile ls command returns tape file metadata from the CTA Catalogue.

However, cta-admin tapefile ls -l also returns the filename, which is part of the disk file metadata, stored in EOS. The use case for this is occasional operator queries to see what files are on a tape.

The current architecture requires CTA to make a query to the EOS frontend for the filename. This was implemented using EOS's gRPC interface. However, this implementation has a number of problems:

  1. Authentication is via a gRPC token. For security reasons, this token is mapped to EOS user nobody, which does not allow us to query the filename of files which do not have UNIX permission bit o+r (or are in a directory without permission). So our current query mechanism is incomplete.
  2. The EOS gRPC interface requires us to set the disk file ID as a uint64 field. This is not portable to dCache which uses a uuid as the disk file ID.
  3. AARNet reported to us a problem with the gRPC interface, see #294 (closed). The investigation showed that there is a problem to get the status of requests for metadata retrieval using the EOS gRPC API.
  4. Operators need to restart cta-frontend if they want to use a temporary eos instance grpc key to perform this EOS filename lookup, which is too intrusive for the service.

Stakeholders

  • The issue affects CTA portability to other disk systems
  • It complicates CTA Frontend and EOS instance configuration
  • The feature is used only by CTA operators who need to run cta-admin tapefile ls -l

Proposal

The proposal is to remove the EOS namespace lookup from the CTA Frontend, which will resolve issues 1-3 above.

To satisfy the needs of CTA operators, it is proposed to add this functionality into the cta-admin client tool or a separate tool for this purpose. The client tool can retrieve the tape metadata as normal using cta-admin tapefile ls, then do its own query to EOS to get the filenames when the -l flag is supplied.

The client can use the normal EOS API and authenticate using Kerberos to avoid the gRPC authentication problem.

This implies that the configuration in /etc/cta/eos.grpc.keytab would no longer be part of the Frontend configuration, but would instead be moved to the configuration of cta-admin (or similar tool).

Edited by Julien Leduc