Release 0.17.1

This release lets you size the backup monitoring sidecar, improves restore parallelism, and makes configuration changes roll the affected pods.

Installation

For new installations, see the Installation guide.

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

Backup monitoring sidecar resources

You can now set the CPU and memory requests and limits for the monitoring sidecar that runs alongside each backup. Set defaults for every backup through the operator Helm values, or override them for a single backup with spec.monitoring.resources.

values.yaml

operator:
  config:
    backup:
      monitoring:
        container:
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"

Default Pod SettingsLearn how to configure default resources for the backup monitoring sidecar.

Bug fixes

• Restores now make full use of the topic parallelism you configure. Previously a restore could take up one of its parallel slots for a topic while that topic was still waiting for one of the maxProducers Kafka producers to free up, which left some slots idle and made large restores slower than expected. Restores now line up a producer first, so every configured slot stays busy and restores finish faster.

• Configuration changes now roll the affected pods. The API, operator, and console deployments previously kept running the old configuration when only a ConfigMap or Secret changed. A config checksum annotation now triggers a rolling update on those changes.

Release notes

For a full list of changes, see the Changelog.