Announcement of new CTA public release: 5.11.18.0-2

Releases
1

New CTA public release

Dear CTA community,

We have made available a new version of CTA in our stable repo:

On top of these changes, we have also done work to further improve the completeness of the CTA Documentation Website. We would highly recommend you have a look, in particular the Operations Section.

This version of CTA was deployed in production at CERN since 28 April 2026.

Installation instructions

  • If setting up CTA for the first time, or upgrading from a version 5.11.x.y-z:
    • Version 5.11.18.0-2 can be installed directly, following these instructions on the CTA docs. Depending on the version previously installed, new configurations may be required.
  • If upgrading from an older CTA major version (5.10.x.y-z):
    • First, install 5.11.0.1-1. This version is required to upgrade the CTA Catalogue version from 14.0 to 15.0
    • After the CTA Catalogue schema migration is complete, the installation of version 5.11.18.0-2 can be performed as described above.

Breaking Changes

This stable release comes with a few important breaking changes outlined below.

1. New CTA Service: cta-maintd

The maintenance process used to be a separate process running within cta-taped. However, this subprocess was not directly tied to any tape hardware and is now a standalone daemon.
This maintenance daemon periodically executes routines that do various tasks within CTA:

  • Reporting to the disk instance
  • Handling repack requests
  • Garbage collection and queue cleanup in the objectstore

This means that for CTA to continue functioning, you will have to deploy this new service: cta-maintd. While this should be relatively straightforward, we outline a few points below:

  • cta-maintd uses TOML for its configuration format. See either the man page of maintd, the bundled cta-maintd.example.toml file or the relevant documentation page
  • cta-maintd does not set its own user and group (unlike taped). As such, it may be necessary to set this user and group in e.g. the Systemd service file to ensure keytabs can be read correctly.
  • We recommend using the following flags for cta-maintd:
    • --log-file PATH for the log file location
    • --config PATH for the config file location
    • --config-strict for strict config checking
    • --runtime-dir PATH for the runtime directory if desired
    • (optional) --config-check if you just want to quickly check whether the config is correct
  • cta-maintd does not interact directly with tape hardware. It is therefore not a requirement to run cta-maintd on the same host as cta-taped
  • Because each cta-taped process came with its own maintenance process, we would recommend starting out by running as many cta-maintd processes as cta-taped for the initial migration. In practice, this will likely be too many, so you can scale down as needed. The various routines in cta-maintd can also be enabled/disabled at will, making the deployment configuration very flexible. Ultimately, we don’t yet have a clear guideline that specifies exactly how many you need.
  • cta-maintd uses the declarative OpenTelemetry format, as this provides increased flexibility in how the OpenTelemetry SDK is configured. See either the bundled cta-otel.example.yaml file or the relevant documentation page
    • While still experimental, the metrics maintd produces may be useful to understand how many replicas you need. See Metrics Documentation
  • To avoid service disruption, ensure all CTA packages (including the new cta-maintd) are updated to the same version simultaneously. Installing a new service may inadvertently update the shared libraries; a version mismatch between cta-taped and underlying libraries such as cta-lib will cause running tape sessions to crash.

With cta-maintd being a new service, it was a great opportunity for us to rethink the way CTA applications are set up and configured.
The various new features such as TOML configuration, declarative OpenTelemetry configuration, strict config checking, health endpoints, runtime metadata files and better signal handling will be rolled out to cta-frontend-grpc and cta-taped over the next few months.
We would be happy to hear your feedback on these changes!

Documentation References:

2. Catalogue Install Behaviour Change

We identified a bug in the installation behaviour of the CTA catalogue libraries.
CTA supports multiple database backends for the catalogue: Postgres and Oracle.
Thanks to a plugin system, CTA only needs one of these two RPMs installed, depending on which backend is used:

  • cta-lib-catalogue-occi
  • cta-lib-catalogue-postgres

That was the theory, at least. In practice, due to a bug, both of these RPMs would always be installed with no way of uninstalling either one when you don’t need them. This has now been fixed.

Old Catalogue Install Behaviour:

  • Installing any CTA package requiring cta-lib-catalogue will install both cta-lib-catalogue-postgres and cta-lib-catalogue-occi.
    • This means even if you are using Postgres for the catalogue, it would still download and install the Oracle-related RPMs.

New Catalogue Install Behaviour:

  • By default, installing any CTA package requiring cta-lib-catalogue will only install cta-lib-catalogue-postgres.
    • That means: dnf install cta-taped will bring in cta-lib-catalogue-postgres, but not cta-lib-catalogue-occi
  • If you are using Oracle for the catalogue, you will have to explicitly install cta-lib-catalogue-occi
    • In this case: dnf install cta-lib-catalogue-occi cta-taped will not bring in cta-lib-catalogue-postgres

In general, CTA will now be happily installed as long as at least one of cta-lib-catalogue-postgres or cta-lib-catalogue-occi is present.

Documentation references:

3. ABI Change opentelemetry-cpp v1.26

The ABI of opentelemetry-cpp v1.26 from cta-dependencies changed w.r.t. previous versions due to a change in build flags.
Upgrading the opentelemetry-cpp RPM to v1.26 before upgrading CTA causes running services with opentelemetry enabled to crash.
Ensure a correct versionlock is in place (such as the ones from cta-release) and ensure CTA and its dependencies are updated simultaneously.

Experimental features

CTA can publish metrics in the OTLP format, using the OpenTelemetry framework mentioned above. This feature is experimental and disabled by default.