add missing bits for new logical backup option

charts/postgres-operator/crds/operatorconfigurations.yaml

@@ -381,6 +381,9 @@ spec:
                     default: "registry.opensource.zalan.do/acid/logical-backup:v1.6.0"
                   logical_backup_google_application_credentials:
                     type: string
+                  logical_backup_job_prefix:
+                    type: string
+                    default: "logical-backup-"
                   logical_backup_provider:
                     type: string
                     default: "s3"

charts/postgres-operator/values-crd.yaml

@@ -252,6 +252,8 @@ configLogicalBackup:
   # path of google cloud service account json file
   # logical_backup_google_application_credentials: ""
 
+  # prefix for the backup job name
+  logical_backup_job_prefix: "logical-backup-"
   # storage provider - either "s3" or "gcs"
   logical_backup_provider: "s3"
   # S3 Access Key ID

charts/postgres-operator/values.yaml

@@ -242,6 +242,7 @@ configLogicalBackup:
   logical_backup_docker_image: "registry.opensource.zalan.do/acid/logical-backup:v1.6.0"
   # path of google cloud service account json file
   # logical_backup_google_application_credentials: ""
+
   # prefix for the backup job name
   logical_backup_job_prefix: "logical-backup-"
   # storage provider - either "s3" or "gcs"

docs/administrator.md

@@ -30,10 +30,10 @@ To trigger the upgrade, increase the version in the cluster manifest. After
 Pods are rotated `configure_spilo` will notice the version mismatch and start
 the old version again. You can then exec into the Postgres container of the
 master instance and call `python3 /scripts/inplace_upgrade.py N` where `N`
-is the number of members of your cluster (see `number_of_instances`). The
+is the number of members of your cluster (see [`numberOfInstances`](https://github.com/zalando/postgres-operator/blob/50cb5898ea715a1db7e634de928b2d16dc8cd969/manifests/minimal-postgres-manifest.yaml#L10)).
-upgrade is usually fast, well under one minute for most DBs. Note, that changes
+The upgrade is usually fast, well under one minute for most DBs. Note, that
-become irrevertible once `pg_upgrade` is called. To understand the upgrade
+changes become irrevertible once `pg_upgrade` is called. To understand the
-procedure, refer to the [corresponding PR in Spilo](https://github.com/zalando/spilo/pull/488).
+upgrade procedure, refer to the [corresponding PR in Spilo](https://github.com/zalando/spilo/pull/488).
 
 ## CRD Validation
 

manifests/configmap.yaml

@@ -64,6 +64,7 @@ data:
   # log_s3_bucket: ""
   logical_backup_docker_image: "registry.opensource.zalan.do/acid/logical-backup:v1.6.0"
   # logical_backup_google_application_credentials: ""
+  logical_backup_job_prefix: "logical-backup-"
   logical_backup_provider: "s3"
   # logical_backup_s3_access_key_id: ""
   logical_backup_s3_bucket: "my-bucket-url"

manifests/operatorconfiguration.crd.yaml

@@ -379,6 +379,7 @@ spec:
                     type: string
                   logical_backup_job_prefix:
                     type: string
+                    default: "logical-backup-"
                   logical_backup_provider:
                     type: string
                     default: "s3"

pkg/apis/acid.zalan.do/v1/crds.go

@@ -1293,6 +1293,9 @@ var OperatorConfigCRDResourceValidation = apiextv1.CustomResourceValidation{
 							"logical_backup_google_application_credentials": {
 								Type: "string",
 							},
+							"logical_backup_job_prefix": {
+								Type: "string",
+							},
 							"logical_backup_provider": {
 								Type: "string",
 							},