Release 0.15.4

This release adds support for using basic authentication alongside OIDC, improves backup metrics reliability for ephemeral storage setups, and persists scraped backup metrics to the database.

Installation

For new installations, see the Installation guide.

For upgrading existing installations, see the associated Upgrading to 0.15.x guide.

Multiple authentication methods

Basic authentication can now be used simultaneously with OIDC. Previously, enabling OIDC disabled basic authentication entirely. When OIDC is configured, basic authentication is disabled by default. New api.config.basicAuth configuration options have been added to support this. Set basicAuth.enabled to true to allow both authentication methods at the same time.

api:
  config:
    security:
      username: <username> # deprecated
      password: <password> # deprecated
      basicAuth:
        enabled: true
        username: "<username>"
        password: "<password>"
      oidc:
        issuerUri: "https://idp.example.com/realms/my-realm"
        audience: "my-audience"

The existing api.config.security.username and api.config.security.password values are deprecated in favor of api.config.security.basicAuth.username and api.config.security.basicAuth.password, but continue to work for backwards compatibility.

Backup metrics persistence and startup scraping

Previously, scraped backup pod metrics were only held in the in-memory cache and never persisted. Only when the backup task sent start and stop events, were metrics persisted. This caused a few problems after a restart:

• With ephemeral storage, the database is empty on restart. There are no cached metrics at all until the first scrape completes.
• With persistent storage, the database still has records, but they are stale until the next scrape cycle.
• If the API/Event Gateway was unavailable while a backup sent its start or stop events, those metrics were lost entirely. This could cause the API to report a wrong list of topics.

The API now scrapes all running backup pods on startup and periodically persists scraped metrics to the database, so metrics are always fresh after a restart regardless of storage type. Rather than writing on every scrape, persistence is batched on a slower interval to reduce database load.

api:
  config:
    backup:
      metrics:
        scrape:
          persist:
            onStartup: true # Scrape backup pods on start up.
            enabled: true  # Persist scraped metrics
            interval: "5m" # Persist every 5 minutes

Release notes

For a full list of changes, see the Changelog.