CTA Frontend¶

The CTA frontend is responsible for serving two different types of requests:

Workflow events, responsible for faciliating things such as archival and retrival of files.
cta-admin commands, which can be used to perform various operations.

The frontend acts as the public interface to CTA.

CTA XRootD SSI Frontend¶

The XrootD/SSI frontend uses the XrootD/SSI framework for client-server communication.

Per the XrootD/SSI documentation, some of the key concepts involved are the Service Provider, the Request and Response types.

Presently, the code for the XrootD SSI frontend is found in two places:

the submodule xrootd-ssi-protobuf-interface
the xroot_plugins directory in CTA

The xrootd-ssi-protobuf-interface submodule binds the google protobuf definitions to the XrootD/SSI Request and Response (Metadata) types. The xroot_plugins directory instantiates the Service Provider and also contains the request processing code.

For authentication, the XrootD/SSI frontend uses SSS (Simple Shared Secrets) to authenticate.

Request Processing¶

The request processing flow is presented in the following diagram:

flowchart LR
   A["XrdSsiPbService::ProcessRequest()"]-.-> B["RequestProc<>::Execute()"]-.-> C["RequestProc<>::ExecuteAction()"]-.-> D["RequestMessage::process()"]-.-> E["WorkFlowEvent::process()"] & F["AdminCmd::process()"] & G["AdminCmdStream::process()"]

Physics workflow events¶

The client (EOS) sends a request to the server (CTA) for each workflow event. Processing the request message is done by the process method of the RequestMessage class (defined in XrdSsiCtaRequestMessage) and handling of the request is done by the methods defined in the WorkFlowEvent class, which fill in the response:

classDiagram
class WorkFlowEvent {
  - const eos::Notification m_event
  - SecurityIdentity m_cliIdentity
  - cta::Catalogue &m_catalogue
  - cta::Scheduler &m_scheduler
  + void processOPENW (xrd::Response &response)
  + void processCREATE (xrd::Response &response)
  + void processPREPARE (xrd::Response &response)
  + void processCLOSEW(xrd::Response &response)
  + void processABORT_PREPARE(xrd::Response &response)
  + void processDELETE(xrd::Response &response)
  + void processUPDATE_FID(xrd::Response &response)
}

CTA-Admin commands¶

Processing the request message is done by the process method of the class AdminCmd in the case of non-streaming commands or the AdminCmdStream class in the case of streaming commands. Non-streaming admin commands are implemented as methods of the CtaAdmin class while streaming admin commands are implemented as methods of CtaAdminStream.

classDiagram
class AdminCmd {
  xrd::Response process()
  void processAdmin_Add(xrd::Response &response)
  void processAdmin_Ch(xrd::Response &response)
}

class AdminCmdStream {
  xrd::Response process()
  void processAdmin_Ls(xrd::Response &response)
  void processArchiveRoute_Ls(xrd::Response &response)
}

AdminCmd <|-- AdminCmdStream

CTA gRPC Frontend¶

The gRPC frontend is mean to be the successor of the XRootD SSI frontend. It is currently undergoing development. The gRPC frontend uses Google's Remote Procedure Calls framework for client-server communication.

Currently the gRPC frontend only serves the physics workflow event requests. The admin commands implementations will be added soon. The gRPC methods wrap the corresponding WorkFlowEvent class methods, as shown in the table below.

gRPC method	common method
CtaRpcImpl::Create()	processCREATE()
CtaRpcImpl::Archive()	processCLOSEW()
CtaRpcImpl::Delete()	processDELETE()
CtaRpcImpl::Retrieve()	processPREPARE()
CtaRpcImpl::CancelRetrieve	processABORT_PREPARE()