Bump version to v4.4.0-beta.2

Author: Jonathan S. Katz

Makefile

@@ -9,7 +9,7 @@ PGO_CMD ?= kubectl
 PGO_IMAGE_PREFIX ?= crunchydata
 PGO_IMAGE_TAG ?= $(PGO_BASEOS)-$(PGO_VERSION)
 PGO_OPERATOR_NAMESPACE ?= pgo
-PGO_VERSION ?= 4.4.0-beta.1
+PGO_VERSION ?= 4.4.0-beta.2
 PGO_PG_VERSION ?= 12
 PGO_PG_FULLVERSION ?= 12.3
 PGO_BACKREST_VERSION ?= 2.27

README.md

@@ -128,7 +128,7 @@ Based on your storage settings in your Kubernetes environment, you may be able t
 
 ```shell
 kubectl create namespace pgo
-kubectl apply -f https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.1/installers/kubectl/postgres-operator.yml
+kubectl apply -f https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.2/installers/kubectl/postgres-operator.yml
 ```
 
 Otherwise, we highly recommend following the instructions from our [Quickstart](https://access.crunchydata.com/documentation/postgres-operator/latest/quickstart/).

bin/push-ccp-to-gcr.sh

@@ -16,7 +16,7 @@
 GCR_IMAGE_PREFIX=gcr.io/crunchy-dev-test
 
 CCP_IMAGE_PREFIX=crunchydata
-CCP_IMAGE_TAG=centos7-12.3-4.4.0-beta.1
+CCP_IMAGE_TAG=centos7-12.3-4.4.0-beta.2
 
 IMAGES=(
 crunchy-prometheus

docs/content/Configuration/configuration.md

@@ -1,7 +1,7 @@
 
 ---
 title: "Configuration Resources"
-Latest Release: 4.4.0-beta.1 {docdate}
+Latest Release: 4.4.0-beta.2 {docdate}
 draft: false
 weight: 2
 ---

docs/content/Configuration/pgo-yaml-configuration.md

@@ -1,7 +1,7 @@
 
 ---
 title: "PGO YAML"
-Latest Release: 4.4.0-beta.1 {docdate}
+Latest Release: 4.4.0-beta.2 {docdate}
 draft: false
 weight: 3
 ---
@@ -16,7 +16,7 @@ The *pgo.yaml* file is broken into major sections as described below:
 |---|---|
 |BasicAuth        | If set to `"true"` will enable Basic Authentication. If set to `"false"`, will allow a valid Operator user to successfully authenticate regardless of the value of the password provided for Basic Authentication. Defaults to `"true".`
 |CCPImagePrefix        |newly created containers will be based on this image prefix (e.g. crunchydata), update this if you require a custom image prefix
-|CCPImageTag        |newly created containers will be based on this image version (e.g. centos7-12.3-4.4.0-beta.1), unless you override it using the --ccp-image-tag command line flag
+|CCPImageTag        |newly created containers will be based on this image version (e.g. centos7-12.3-4.4.0-beta.2), unless you override it using the --ccp-image-tag command line flag
 |Port        | the PostgreSQL port to use for new containers (e.g. 5432)
 |PGBadgerPort | the port used to connect to pgbadger (e.g. 10000)
 |ExporterPort | the port used to connect to postgres exporter (e.g. 9187)

docs/content/Security/install-postgres-operator-rbac.md

@@ -7,9 +7,9 @@ weight: 7
 
 ## Installation of PostgreSQL Operator RBAC
 
-For a list of the RBAC required to install the PostgreSQL Operator, please view the [`postgres-operator.yml`](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.1/installers/kubectl/postgres-operator.yml) file:
+For a list of the RBAC required to install the PostgreSQL Operator, please view the [`postgres-operator.yml`](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.2/installers/kubectl/postgres-operator.yml) file:
 
-[https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.1/installers/kubectl/postgres-operator.yml](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.1/installers/kubectl/postgres-operator.yml)
+[https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.2/installers/kubectl/postgres-operator.yml](https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.4.0-beta.2/installers/kubectl/postgres-operator.yml)
 
 The first step is to install the PostgreSQL Operator RBAC configuration.  This can be accomplished  by running:
 

docs/content/Upgrade/_index.md

@@ -1,6 +1,6 @@
 ---
 title: "Upgrade"
-Latest Release: 4.4.0-beta.1 {docdate}
+Latest Release: 4.4.0-beta.2 {docdate}
 draft: false
 weight: 80
 ---

docs/content/Upgrade/automatedupgrade.md

@@ -1,6 +1,6 @@
 ---
 title: "Automated PostgreSQL Operator Upgrade - Operator 4.1+"
-Latest Release: 4.4.0-beta.1 {docdate}
+Latest Release: 4.4.0-beta.2 {docdate}
 draft: false
 weight: 80
 ---
@@ -73,7 +73,7 @@ export EXCLUDE_OS_TRUST=false
 
 Then, for either 4.1.X or 4.2.X, 
 
-Update the `PGO_VERSION` variable to `4.4.0-beta.1`
+Update the `PGO_VERSION` variable to `4.4.0-beta.2`
 
 Finally, source this file with 
 ```

docs/content/Upgrade/manual/upgrade35.md

@@ -1,21 +1,21 @@
 ---
 title: "Manual Upgrade - Operator 3.5"
-Latest Release: 4.4.0-beta.1 {docdate}
+Latest Release: 4.4.0-beta.2 {docdate}
 draft: false
 weight: 8
 ---
 
-## Upgrading the Crunchy PostgreSQL Operator from Version 3.5 to 4.4.0-beta.1
+## Upgrading the Crunchy PostgreSQL Operator from Version 3.5 to 4.4.0-beta.2
 
-This section will outline the procedure to upgrade a given cluster created using PostgreSQL Operator 3.5.x to PostgreSQL Operator version 4.4.0-beta.1. This version of the PostgreSQL Operator has several fundamental changes to the existing PGCluster structure and deployment model. Most notably, all PGClusters use the new Crunchy PostgreSQL HA container in place of the previous Crunchy PostgreSQL containers. The use of this new container is a breaking change from previous versions of the Operator.
+This section will outline the procedure to upgrade a given cluster created using PostgreSQL Operator 3.5.x to PostgreSQL Operator version 4.4.0-beta.2. This version of the PostgreSQL Operator has several fundamental changes to the existing PGCluster structure and deployment model. Most notably, all PGClusters use the new Crunchy PostgreSQL HA container in place of the previous Crunchy PostgreSQL containers. The use of this new container is a breaking change from previous versions of the Operator.
 
 #### Crunchy PostgreSQL High Availability Containers
 
-Using the PostgreSQL Operator 4.4.0-beta.1 requires replacing your `crunchy-postgres` and `crunchy-postgres-gis` containers with the `crunchy-postgres-ha` and `crunchy-postgres-gis-ha` containers respectively. The underlying PostgreSQL installations in the container remain the same but are now optimized for Kubernetes environments to provide the new high-availability functionality.
+Using the PostgreSQL Operator 4.4.0-beta.2 requires replacing your `crunchy-postgres` and `crunchy-postgres-gis` containers with the `crunchy-postgres-ha` and `crunchy-postgres-gis-ha` containers respectively. The underlying PostgreSQL installations in the container remain the same but are now optimized for Kubernetes environments to provide the new high-availability functionality.
 
 A major change to this container is that the PostgreSQL process is now managed by Patroni. This allows a PostgreSQL cluster that is deployed by the PostgreSQL Operator to manage its own uptime and availability, to elect a new leader in the event of a downtime scenario, and to automatically heal after a failover event.
 
-When creating your new clusters using version 4.4.0-beta.1 of the PostgreSQL Operator, the `pgo create cluster` command will automatically use the new `crunchy-postgres-ha` image if the image is unspecified. If you are creating a PostGIS enabled cluster, please be sure to use the updated image name, as with the command:
+When creating your new clusters using version 4.4.0-beta.2 of the PostgreSQL Operator, the `pgo create cluster` command will automatically use the new `crunchy-postgres-ha` image if the image is unspecified. If you are creating a PostGIS enabled cluster, please be sure to use the updated image name, as with the command:
 
 ```
 pgo create cluster mygiscluster --ccp-image=crunchy-postgres-gis-ha
@@ -31,7 +31,7 @@ You will need the following items to complete the upgrade:
 
 ##### Step 1
 
-Create a new Linux user with the same permissions as the existing user used to install the Crunchy PostgreSQL Operator. This is necessary to avoid any issues with environment variable differences between 3.5 and 4.4.0-beta.1.
+Create a new Linux user with the same permissions as the existing user used to install the Crunchy PostgreSQL Operator. This is necessary to avoid any issues with environment variable differences between 3.5 and 4.4.0-beta.2.
 
 ##### Step 2
 
@@ -101,7 +101,7 @@ $COROOT/deploy/remove-crd.sh
 
 ##### Step 6
 
-Log in as your new Linux user and install the 4.4.0-beta.1 PostgreSQL Operator as described in the [Bash Installation Procedure]( {{< relref "installation/other/bash.md" >}}).
+Log in as your new Linux user and install the 4.4.0-beta.2 PostgreSQL Operator as described in the [Bash Installation Procedure]( {{< relref "installation/other/bash.md" >}}).
 
 Be sure to add the existing namespace to the Operator's list of watched namespaces (see the [Namespace]( {{< relref "architecture/namespace.md" >}}) section of this document for more information) and make sure to avoid overwriting any existing data storage.
 
@@ -110,7 +110,7 @@ We strongly recommend that you create a test cluster before proceeding to the ne
 
 ##### Step 7
 
-Once the Operator is installed and functional, create a new 4.4.0-beta.1 cluster matching the cluster details recorded in Step 1. Be sure to use the primary PVC name (also noted in Step 1) and the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs.
+Once the Operator is installed and functional, create a new 4.4.0-beta.2 cluster matching the cluster details recorded in Step 1. Be sure to use the primary PVC name (also noted in Step 1) and the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs.
 
 NOTE: If you have existing pgBackRest backups stored that you would like to have available in the upgraded cluster, you will need to follow the [PVC Renaming Procedure]( {{< relref "Upgrade/manual/upgrade35#pgbackrest-repo-pvc-renaming" >}}).
 
@@ -122,7 +122,7 @@ pgo create cluster <clustername> -n <namespace>
 
 ##### Step 8
 
-Manually update the old leftover Secrets to use the new label as defined in 4.4.0-beta.1:
+Manually update the old leftover Secrets to use the new label as defined in 4.4.0-beta.2:
 
 ```
 kubectl -n <namespace> label secret/<clustername>-postgres-secret pg-cluster=<clustername> -n <namespace>

docs/content/Upgrade/manual/upgrade4.md

@@ -1,23 +1,23 @@
 ---
 title: "Manual Upgrade - Operator 4"
-Latest Release: 4.4.0-beta.1 {docdate}
+Latest Release: 4.4.0-beta.2 {docdate}
 draft: false
 weight: 8
 ---
 
 ## Manual PostgreSQL Operator 4 Upgrade Procedure
 
-Below are the procedures for upgrading to version 4.4.0-beta.1 of the Crunchy PostgreSQL Operator using the Bash or Ansible installation methods. This version of the PostgreSQL Operator has several fundamental changes to the existing PGCluster structure and deployment model. Most notably for those upgrading from 4.1 and below, all PGClusters use the new Crunchy PostgreSQL HA container in place of the previous Crunchy PostgreSQL containers. The use of this new container is a breaking change from previous versions of the Operator did not use the HA containers.
+Below are the procedures for upgrading to version 4.4.0-beta.2 of the Crunchy PostgreSQL Operator using the Bash or Ansible installation methods. This version of the PostgreSQL Operator has several fundamental changes to the existing PGCluster structure and deployment model. Most notably for those upgrading from 4.1 and below, all PGClusters use the new Crunchy PostgreSQL HA container in place of the previous Crunchy PostgreSQL containers. The use of this new container is a breaking change from previous versions of the Operator did not use the HA containers.
 
 NOTE: If you are upgrading from Crunchy PostgreSQL Operator version 4.1.0 or later, the [Automated Upgrade Procedure](/upgrade/automatedupgrade) is recommended. If you are upgrading PostgreSQL 12 clusters, you MUST use the [Automated Upgrade Procedure](/upgrade/automatedupgrade). 
 
 #### Crunchy PostgreSQL High Availability Containers
 
-Using the PostgreSQL Operator 4.4.0-beta.1 requires replacing your `crunchy-postgres` and `crunchy-postgres-gis` containers with the `crunchy-postgres-ha` and `crunchy-postgres-gis-ha` containers respectively. The underlying PostgreSQL installations in the container remain the same but are now optimized for Kubernetes environments to provide the new high-availability functionality.
+Using the PostgreSQL Operator 4.4.0-beta.2 requires replacing your `crunchy-postgres` and `crunchy-postgres-gis` containers with the `crunchy-postgres-ha` and `crunchy-postgres-gis-ha` containers respectively. The underlying PostgreSQL installations in the container remain the same but are now optimized for Kubernetes environments to provide the new high-availability functionality.
 
 A major change to this container is that the PostgreSQL process is now managed by Patroni. This allows a PostgreSQL cluster that is deployed by the PostgreSQL Operator to manage its own uptime and availability, to elect a new leader in the event of a downtime scenario, and to automatically heal after a failover event.
 
-When creating your new clusters using version 4.4.0-beta.1 of the PostgreSQL Operator, the `pgo create cluster` command will automatically use the new `crunchy-postgres-ha` image if the image is unspecified. If you are creating a PostGIS enabled cluster, please be sure to use the updated image name, as with the command:
+When creating your new clusters using version 4.4.0-beta.2 of the PostgreSQL Operator, the `pgo create cluster` command will automatically use the new `crunchy-postgres-ha` image if the image is unspecified. If you are creating a PostGIS enabled cluster, please be sure to use the updated image name, as with the command:
 
 ```
 pgo create cluster mygiscluster --ccp-image=crunchy-postgres-gis-ha
@@ -35,7 +35,7 @@ Below are the procedures for upgrading the PostgreSQL Operator and PostgreSQL cl
 
 You will need the following items to complete the upgrade:
 
-* The latest 4.4.0-beta.1 code for the Postgres Operator available
+* The latest 4.4.0-beta.2 code for the Postgres Operator available
 
 These instructions assume you are executing in a terminal window and that your user has admin privileges in your Kubernetes or Openshift environment.
 
@@ -116,7 +116,7 @@ NOTE: Please note the name of each cluster, the namespace used, and be sure not
 
 ##### Step 4
 
-Save a copy of your current inventory file with a new name (such as `inventory.backup)` and checkout the latest 4.4.0-beta.1 tag of the Postgres Operator.
+Save a copy of your current inventory file with a new name (such as `inventory.backup)` and checkout the latest 4.4.0-beta.2 tag of the Postgres Operator.
 
 
 ##### Step 5
@@ -147,7 +147,7 @@ We strongly recommend that you create a test cluster before proceeding to the ne
 
 ##### Step 8
 
-Once the Operator is installed and functional, create a new 4.4.0-beta.1 cluster matching the cluster details recorded in Step 1. Be sure to use the primary PVC name (also noted in Step 1) and the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs. 
+Once the Operator is installed and functional, create a new 4.4.0-beta.2 cluster matching the cluster details recorded in Step 1. Be sure to use the primary PVC name (also noted in Step 1) and the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs. 
 
 NOTE: If you have existing pgBackRest backups stored that you would like to have available in the upgraded cluster, you will need to follow the [PVC Renaming Procedure]( {{< relref "Upgrade/manual/upgrade4#pgbackrest-repo-pvc-renaming" >}}).
 
@@ -284,7 +284,7 @@ $PGOROOT/deploy/cleanup-rbac.sh
 For versions 4.0, 4.1 and 4.2, update environment variables in the bashrc:
 
 ```
-export PGO_VERSION=4.4.0-beta.1
+export PGO_VERSION=4.4.0-beta.2
 ```
 
 NOTE: This will be the only update to the bashrc file for 4.2.
@@ -341,9 +341,9 @@ source ~/.bashrc
 
 ##### Step 8
 
-Ensure you have checked out the latest 4.4.0-beta.1 version of the source code and update the pgo.yaml file in `$PGOROOT/conf/postgres-operator/pgo.yaml`
+Ensure you have checked out the latest 4.4.0-beta.2 version of the source code and update the pgo.yaml file in `$PGOROOT/conf/postgres-operator/pgo.yaml`
 
-You will want to use the 4.4.0-beta.1 pgo.yaml file and update custom settings such as image locations, storage, and resource configs.
+You will want to use the 4.4.0-beta.2 pgo.yaml file and update custom settings such as image locations, storage, and resource configs.
 
 ##### Step 9
 
@@ -359,7 +359,7 @@ You will need to update the `$HOME/.pgouser`file to match the values you set in
 
 ##### Step 10
 
-Install the 4.4.0-beta.1 Operator:
+Install the 4.4.0-beta.2 Operator:
 
 Setup the configured namespaces:
 
@@ -387,7 +387,7 @@ kubectl get pod -n <operator namespace>
 
 ##### Step 11
 
-Next, update the PGO client binary to 4.4.0-beta.1 by replacing the existing 4.X binary with the latest 4.4.0-beta.1 binary available.
+Next, update the PGO client binary to 4.4.0-beta.2 by replacing the existing 4.X binary with the latest 4.4.0-beta.2 binary available.
 
 You can run:
 
@@ -416,7 +416,7 @@ make deployoperator
 
 ##### Step 13
 
-The Operator is now upgraded to 4.4.0-beta.1 and all users and roles have been recreated.
+The Operator is now upgraded to 4.4.0-beta.2 and all users and roles have been recreated.
 Verify this by running:
 
 ```
@@ -427,7 +427,7 @@ We strongly recommend that you create a test cluster before proceeding to the ne
 
 ##### Step 14
 
-Once the Operator is installed and functional, create a new 4.4.0-beta.1 cluster matching the cluster details recorded in Step 1. Be sure to use the same name and the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs. A simple example is given below, but more information on cluster creation can be found [here](/pgo-client/common-tasks#creating-a-postgresql-cluster)
+Once the Operator is installed and functional, create a new 4.4.0-beta.2 cluster matching the cluster details recorded in Step 1. Be sure to use the same name and the same major PostgreSQL version as was used previously. This will allow the new clusters to utilize the existing PVCs. A simple example is given below, but more information on cluster creation can be found [here](/pgo-client/common-tasks#creating-a-postgresql-cluster)
 
 NOTE: If you have existing pgBackRest backups stored that you would like to have available in the upgraded cluster, you will need to follow the [PVC Renaming Procedure]( {{< relref "Upgrade/manual/upgrade4#pgbackrest-repo-pvc-renaming" >}}).