Bump operator to v1.13.0 (#2729)

* bump operator to v1.13.0
* align configmap with CRD config
* remove default from CRD config option additional_secret_mount_path
* enable automatic major version upgrades by default

docs/administrator.md

@@ -70,7 +70,7 @@ the manifest. Still, a rolling update would be triggered updating the
 script will notice the version mismatch and start the old version again.
 
 In this scenario the major version could then be run by a user from within the
-master pod. Exec into the container and run:
+primary pod. Exec into the container and run:
 ```bash
 python3 /scripts/inplace_upgrade.py N
 ```
@@ -81,6 +81,9 @@ upgrade procedure, refer to the [corresponding PR in Spilo](https://github.com/z
 
 When `major_version_upgrade_mode` is set to `manual` the operator will run
 the upgrade script for you after the manifest is updated and pods are rotated.
+It is also possible to define `maintenanceWindows` in the Postgres manifest to
+better control when such automated upgrades should take place after increasing
+the version.
 
 ## Non-default cluster domain
 
@@ -1452,7 +1455,7 @@ make docker
 
 # build in image in minikube docker env
 eval $(minikube docker-env)
-docker build -t ghcr.io/zalando/postgres-operator-ui:v1.12.2 .
+docker build -t ghcr.io/zalando/postgres-operator-ui:v1.13.0 .
 
 # apply UI manifests next to a running Postgres Operator
 kubectl apply -f manifests/

docs/reference/cluster_manifest.md

@@ -115,9 +115,9 @@ These parameters are grouped directly under  the `spec` key in the manifest.
   inaccessible from outside of the Kubernetes cluster.
 
 * **maintenanceWindows**
-  a list defines specific time frames when major version upgrades are permitted
-  to occur, restricting major version upgrades to these designated periods only.
-  Accepted formats include "01:00-06:00" for daily maintenance windows or 
+  a list which defines specific time frames when certain maintenance operations
+  are allowed. So far, it is only implemented for automatic major version
+  upgrades. Accepted formats are "01:00-06:00" for daily maintenance windows or 
   "Sat:00:00-04:00" for specific days, with all times in UTC.
 
 * **users**

docs/reference/operator_parameters.md

@@ -242,7 +242,7 @@ CRD-configuration, they are grouped under the `major_version_upgrade` key.
   `"manual"` = manifest triggers action,
   `"full"` = manifest and minimal version violation trigger upgrade.
   Note, that with all three modes increasing the version in the manifest will
-  trigger a rolling update of the pods. The default is `"off"`.
+  trigger a rolling update of the pods. The default is `"manual"`.
 
 * **major_version_upgrade_team_allow_list**
   Upgrades will only be carried out for clusters of listed teams when mode is
@@ -822,7 +822,7 @@ grouped under the `logical_backup` key.
   runs `pg_dumpall` on a replica if possible and uploads compressed results to
   an S3 bucket under the key `/<configured-s3-bucket-prefix>/<pg_cluster_name>/<cluster_k8s_uuid>/logical_backups`.
   The default image is the same image built with the Zalando-internal CI
-  pipeline. Default: "ghcr.io/zalando/postgres-operator/logical-backup:v1.12.2"
+  pipeline. Default: "ghcr.io/zalando/postgres-operator/logical-backup:v1.13.0"
 
 * **logical_backup_google_application_credentials**
   Specifies the path of the google cloud service account json file. Default is empty.

docs/user.md

@@ -758,7 +758,7 @@ If you need to define a `nodeAffinity` for all your Postgres clusters use the
 ## In-place major version upgrade
 
 Starting with Spilo 13, operator supports in-place major version upgrade to a
-higher major version (e.g. from PG 11 to PG 13). To trigger the upgrade,
+higher major version (e.g. from PG 14 to PG 16). To trigger the upgrade,
 simply increase the version in the manifest. It is your responsibility to test
 your applications against the new version before the upgrade; downgrading is
 not supported. The easiest way to do so is to try the upgrade on the cloned