diff --git a/kubernetes/infrastructure/cnpg-barman-plugin/manifest.yaml b/kubernetes/infrastructure/cnpg-barman-plugin/manifest.yaml index 207e499d..606c8e04 100644 --- a/kubernetes/infrastructure/cnpg-barman-plugin/manifest.yaml +++ b/kubernetes/infrastructure/cnpg-barman-plugin/manifest.yaml @@ -917,11 +917,27 @@ subjects: name: plugin-barman-cloud namespace: database --- +# stringData, NOT base64 `data`. An image reference is not a secret, and +# encoding it here had two real costs: no reviewer sees a version change in a +# diff, and no $imagepolicy marker can be attached to a base64 blob. The result +# was that automation advanced the controller to v0.14.0 while this sidecar sat +# at v0.12.0 — a two-minor skew in the component that performs every base backup +# and WAL archive, invisible until someone read the pod spec (#535). +# +# The Secret KIND is kept because the controller reads it via secretKeyRef +# (deployment env SIDECAR_IMAGE); changing it to a ConfigMap would need a matching +# edit to that reference and diverge further from upstream. stringData is +# accepted identically by the API server and serialised into `data` on write. +# +# The name carries a kustomize hash suffix from upstream's secretGenerator. It is +# static here, so editing the value does NOT change the name and the deployment's +# secretKeyRef stays valid. +# +# IF YOU RE-IMPORT THE UPSTREAM MANIFEST: upstream ships this as base64 `data` +# with no marker. Re-apply this block, or the skew silently returns. apiVersion: v1 -data: - SIDECAR_IMAGE: | - Z2hjci5pby9jbG91ZG5hdGl2ZS1wZy9wbHVnaW4tYmFybWFuLWNsb3VkLXNpZGVjYXI6dj - AuMTIuMA== +stringData: + SIDECAR_IMAGE: ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.14.0 # {"$imagepolicy": "flux-system:cnpg-barman-plugin-sidecar"} kind: Secret metadata: name: plugin-barman-cloud-kg5c2795f7 diff --git a/kubernetes/infrastructure/image-automation/cnpg-barman-plugin.yaml b/kubernetes/infrastructure/image-automation/cnpg-barman-plugin.yaml index 75f8e445..8f091a63 100644 --- a/kubernetes/infrastructure/image-automation/cnpg-barman-plugin.yaml +++ b/kubernetes/infrastructure/image-automation/cnpg-barman-plugin.yaml @@ -28,3 +28,40 @@ spec: policy: semver: range: "0.x" +--- +# The SIDECAR image, tracked separately from the controller above. +# +# These are two DIFFERENT images that must move together: +# plugin-barman-cloud the controller, in the database namespace +# plugin-barman-cloud-sidecar injected into every Postgres pod +# +# Only the controller was tracked, so automation walked it from v0.12.0 to +# v0.14.0 while the sidecar stayed at v0.12.0 — a two-minor skew in the +# component that performs every base backup and WAL archive (#535). The skew was +# invisible because the sidecar tag was base64-encoded inside a Secret, where no +# $imagepolicy marker can reach it and no reviewer would see it in a diff. +apiVersion: image.toolkit.fluxcd.io/v1 +kind: ImageRepository +metadata: + name: cnpg-barman-plugin-sidecar + namespace: flux-system +spec: + image: ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar + interval: 1h +--- +# Same filter and range as the controller policy deliberately: the two images +# are released together and must not be allowed to drift apart again. +apiVersion: image.toolkit.fluxcd.io/v1 +kind: ImagePolicy +metadata: + name: cnpg-barman-plugin-sidecar + namespace: flux-system +spec: + imageRepositoryRef: + name: cnpg-barman-plugin-sidecar + filterTags: + pattern: '^v(?P\d+\.\d+\.\d+)$' + extract: '$ver' + policy: + semver: + range: "0.x"