feat(cluster): expose stopDelay for fast scheduledbackups cleanup (#941)

The barman-plugin-scheduledbackups test intermittently fails with
'context deadline exceeded' during cleanup. The chart forces immediate:
true on scheduled backups (templates/scheduled-backups.yaml), so a backup
is still running when cleanup starts; Barman blocks instance shutdown
until it completes, pushing teardown past the 5m cleanup budget on GitHub
runners.

Expose cluster.stopDelay in the chart (values + schema + template), mapping
to the CNPG Cluster spec.stopDelay, which also sets the pod's
terminationGracePeriodSeconds. The scheduledbackups test sets stopDelay: 30
so the instance is force-stopped promptly at teardown, interrupting the
still-running backup. That's acceptable because this test only verifies a
backup is started from the ScheduledBackup; backup success is covered by
barman-plugin-backup-restore.

Result: passes reliably and runs in ~75s (down from ~6m, previously timing
out). Verified green in fork CI. This is the 'help it clean up faster'
approach rather than raising the cleanup timeout.

Supersedes #940. Supplements #924.

Signed-off-by: Abdullah Alaqeel <abdullah.t.aqeel@gmail.com>

Author: aqeelat

charts/cluster/templates/cluster.yaml

@@ -56,6 +56,9 @@ spec:
 
   primaryUpdateMethod: {{ .Values.cluster.primaryUpdateMethod }}
   primaryUpdateStrategy: {{ .Values.cluster.primaryUpdateStrategy }}
+  {{- with .Values.cluster.stopDelay }}
+  stopDelay: {{ . }}
+  {{- end }}
   logLevel: {{ .Values.cluster.logLevel }}
   {{- with .Values.cluster.certificates }}
   certificates:

charts/cluster/test/barman-plugin-scheduledbackups/01-scheduledbackups_cluster.yaml

@@ -2,6 +2,12 @@ type: postgresql
 mode: standalone
 cluster:
   instances: 1
+  # Use a short stopDelay so teardown is fast: the chart forces `immediate: true`
+  # on scheduled backups, so a backup can still be running at cleanup time, and
+  # Barman blocks instance shutdown until it completes. A low stopDelay caps the
+  # pod's terminationGracePeriodSeconds, force-stopping the instance promptly.
+  # This test only needs to observe that a backup was started.
+  stopDelay: 30
   storage:
     size: 256Mi
 

charts/cluster/values.schema.json

@@ -536,6 +536,12 @@
           "description": "Strategy to follow to upgrade the primary server during a rolling update procedure, after all replicas have been\nsuccessfully updated: it can be automated (unsupervised - default) or manual (supervised)",
           "type": "string"
         },
+        "stopDelay": {
+          "default": 1800,
+          "description": "The time in seconds that is allowed for the instance to wait for the shutdown to complete before being forcefully\nterminated. Also sets the pod's terminationGracePeriodSeconds. Defaults to 1800 (30m) when unset.",
+          "minimum": 1,
+          "type": "integer"
+        },
         "priorityClassName": {
           "default": "",
           "type": "string"

charts/cluster/values.yaml

@@ -253,6 +253,11 @@ cluster:
   # successfully updated: it can be automated (unsupervised - default) or manual (supervised)
   primaryUpdateStrategy: unsupervised
 
+  # -- The time in seconds that is allowed for the instance to wait for the shutdown
+  # to complete before being forcefully terminated. Also sets the pod's terminationGracePeriodSeconds.
+  # Defaults to 1800 (30m) when unset, per the operator default.
+  # stopDelay: 1800
+
   # -- The instances' log level, one of the following values: error, warning, info (default), debug, trace
   logLevel: "info"