Backups are sometimes written to $(SCOPE) instead of <CLUSTERNAME>

[eberlep]

I first thought this was related to 341, but it seems to affect prod instances as well.

While this is no problem for the backup itself, a clone into another database does not work as the clone cannot find the backups (as the backups are written to the wrong "folder").

[eberlep]

~  $ helm list
NAME            NAMESPACE               REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
postgreslet     postgreslet-system      3               2022-05-13 19:32:34.680935336 +0000 UTC deployed        postgreslet-0.4.0 

~  $ k get cm postgreslet -o yaml
apiVersion: v1
data:
  CUSTOM_PSP_NAME: postgreslet
  ENABLE_CRD_VALIDATION: "False"
  ENABLE_LEADER_ELECTION: "false"
  ENABLE_NETPOL: "True"
  ETCD_HOST: ""
  LOAD_BALANCER_IP: *REMOVED*
  MAJOR_VERSION_UPGRADE_MODE: manual
  METRICS_ADDR_CTRL_MGR: "0"
  METRICS_ADDR_SVC_MGR: :8080
  OPERATOR_IMAGE: registry.fits.cloud/cloud-services/images/postgres-operator:v1.7.0-1-g711648b-dirty
  PARTITION_ID: *REMOVED*
  PORT_RANGE_SIZE: "8000"
  PORT_RANGE_START: "32000"
  POSTGRES_IMAGE: cybertecpostgresql/spilo:2.1-p1_de-sync-standby-cluster_0.3.2_8c82e1e
  POSTGRES_PARAM_BLOCKLIST: ""
  POSTGRESLET_NAMESPACE: postgreslet-system
  RUN_AS_NON_ROOT: "False"
  SIDECARS_CONFIGMAP_NAME: postgreslet-postgres-sidecars
  STANDBY_CLUSTERS_SOURCE_RANGES: *REMOVED*
  STORAGE_CLASS: csi-lvm-sc-linear
  TENANT: *REMOVED*

[eberlep]

The WAL?_S3_PREFIX variables seem to be set incorrectly:

$ grep -i SCOPE /run/etc/wal-e.d/env/*
/run/etc/wal-e.d/env/WALE_S3_PREFIX:s3://backup-12345/$(SCOPE)
/run/etc/wal-e.d/env/WALG_S3_PREFIX:s3://backup-12345/$(SCOPE)

[eberlep]

$SCOPE should be set as root and postgres inside the container.

In the case the backup isn't working, SCOPE is only set for root but not for postgres.