Add v4.4.0 release notes

Author: Jonathan S. Katz

docs/content/releases/4.4.0.md

@@ -0,0 +1,113 @@
+---
+title: "4.4.0"
+date:
+draft: false
+weight: 80
+---
+
+Crunchy Data announces the release of the PostgreSQL Operator 4.4.0 on July DD, 2020.
+
+The PostgreSQL Operator is released in conjunction with the [Crunchy Container Suite](https://github.com/CrunchyData/crunchy-containers/).
+
+The PostgreSQL Operator 4.4.0 release includes the following software versions upgrades:
+
+- PostGIS 3.0 is now supported. There is now a manual upgrade path between PostGIS containers.
+- pgRouting is now included in the PostGIS containers.
+- pgBackRest is now at version 2.27.
+- pgBouncer is now at version 1.14.
+
+PostgreSQL Operator is tested with Kubernetes 1.15 - 1.18, OpenShift 3.11+, OpenShift 4.4+, Google Kubernetes Engine (GKE), and VMware Enterprise PKS 1.3+.
+
+## Major Features
+
+- Create New PostgreSQL Clusters from pgBackRest Repositories
+- Improvements to RBAC Reconciliation.
+- TLS Authentication for PostgreSQL Instances.
+- A Helm Chart is now available and support for deploying the PostgreSQL Operator.
+
+### Create New PostgreSQL Clusters from pgBackRest Repositories
+
+A technique frequently used in PostgreSQL data management is to have a pgBackRest repository that can be used to create new PostgreSQL clusters. This can be helpful for a variety of purposes:
+
+- Creating a development or test database from a production data set
+- Performing a point-in-time-restore on a database that is separate from the primary database
+
+and more.
+
+This can be accomplished with the following new flags on `pgo create cluster`:
+
+- `--restore-from`: used to specify the name of the pgBackRest repository to restore from via the name of the PostgreSQL cluster (whether the PostgreSQL cluster is active or not).
+- `--restore-opts`: used to specify additional options like the ones specified to `pgbackrest restore` (e.g. `--type` and `--target` if performing a point-in-time-recovery).
+
+Only one restore can be performed against a pgBackRest repository at a given time.
+
+### RBAC Reconciliation
+
+PostgreSQL Operator 4.3 introduced a change that allows for the Operator to manage the role-based access controls (RBAC) based upon the [Namespace Operating mode](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/namespace/#namespace-operating-modes) that is selected. This ensures that the PostgreSQL Operator is able to function correctly within the Namespace or Namespaces that it is permitted to access. This includes Service Accounts, Roles, and Role Bindings within a Namespace.
+
+PostgreSQL Operator 4.4 removes the requirements of granting the PostgreSQL Operator `bind` and `escalate` privileges for being able to reconcile its own RBAC, and further defines which RBAC is specifically required to use the PostgreSQL Operator (i.e. the removal of wildcard `*` privileges). The permissions that the PostgreSQL Operator requires to perform the reconciliation are assigned when it is deployed and is a function of which `NAMESPACE_MODE` is selected (`dynamic`, `readonly`, or `disabled`).
+
+This change renames the `DYNAMIC_RBAC` parameter in the installer to `RECONCILE_RBAC` and is set to `true` by default.
+
+For more information on how RBAC reconciliation works, please visit the [RBAC reconciliation documentation](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/namespace/).
+
+### TLS Authentication for PostgreSQL Instances
+
+[Certificate-based authentication](https://www.postgresql.org/docs/current/auth-cert.html) is a powerful PostgreSQL feature that allows for a PostgreSQL client to authenticate using a TLS certificate. While there are a variety of permutations for this can be set up, we can at least create a standardized way for enabling the replication connection to authenticate with a certificate, as we do have a known certificate authority.
+
+PostgreSQL Operator 4.4 introduces the `--replication-tls-secret` flag on the `pgo create cluster` command, which, if specified and if the prerequisites are specified (`--server-tls-secret` and `--server-ca-secret`), then the replication account ("primaryuser") is configured to use certificate-based authentication. Combine with `--tls-only` for powerful results.
+
+Note that the common name (CN) on the certificate MUST be "primaryuser", otherwise one must specify a mapping in a `pg_ident` configuration block to map to "primary" user.
+
+When mounted to the container, the connection `sslmode` that the replication user uses is set to `verify-ca` by default. We can make that guarantee based on the certificate authority that is being mounted. Using `verify-full` would cause the Operator to make assumptions about the cluster that we cannot make, and as such a custom `pg_ident` configuration block is needed for that. However, using `verify-full` allows for mutual authentication between primary and replica.
+
+## Breaking Changes
+
+- The parameter to set the RBAC reconciliation settings is renamed to `RECONCILE_RBAC` (from `DYNAMIC_RBAC`).
+
+## Features
+
+- Added support for using the URI path style feature of pgBackRest. This includes:
+  - Adding the `BackrestS3URIStyle` configuration parameter to the PostgreSQL Operator ConfigMap (`pgo.yaml`), which accepts the values of `host` or `path`.
+  - Adding the `--pgbackrest-s3-uri-style` flag to `pgo create cluster`, which accepts values of `host` or `path`.
+- Added support to disable TLS verification when connecting to a pgBackRest repository. This includes:
+  - Adding the `BackrestS3VerifyTLS ` configuration parameter to the PostgreSQL Operator ConfigMap (`pgo.yaml`). Defaults to `true`.
+  - Adding the `--pgbackrest-s3-verify-tls` flag to `pgo create cluster`, which accepts values of `true` or `false`.
+- Perform a `pg_dump` from a specific database using the `--database` flag when using `pgo backup` with `--backup-type=pgdump`.
+- Restore a `pg_dump` to a specific database using the `--pgdump-database` flag using `pgo restore` when `--backup-type=pgdump` is specified.
+- Allow for support of authentication parameters in the `pgha-config` (e.g. `sslmode`). See the documentation for words of caution on using these.
+- Add the `--client` flag to `pgo version` to output the client version of `pgo`.
+- A Helm Chart using Helm v3 is now available.
+
+## Changes
+
+- `pgo clone` is now deprecated. For a better cloning experience, please use [`pgo create cluster --restore-from`](https://access.crunchydata.com/documentation/postgres-operator/latest/pgo-client/common-tasks/#clone-a-postgresql-cluster)
+- The PostgreSQL cluster scope is now utilized to identify and sync the ConfigMap responsible for the DCS for a PostgreSQL cluster.
+- The `PGMONITOR_PASSWORD` is now populated by an environmental variable secret. This environmental variable is only set on a primary instance as it is only needed at the time a PostgreSQL cluster is initialized.
+- Remove "Operator Start Time" from `pgo status` as it is more convenient and accurate to get this information from `kubectl` and the like, and it was not working due to RBAC privileges. (Reported by @mw-0).
+- Removed unused pgcluster attributes `PrimaryHost` and `SecretFrom`.
+- `pgo-rmdata` container no longer runs as the `root` user, but as `daemon` (UID 2)
+- Remove dependency on the `expenv` binary that was included in the PostgreSQL Operator release. All `expenv` calls were either replaced with the native `envsubst` program or removed.
+
+## Fixes
+
+- Add validation to ensure that limits for CPU/memory are greater-than-or-equal-to the requests. This applies to any command that can set a limit/request.
+- Ensure PVC capacities are being accurately reported when using `pgo show cluster`
+- Ensure WAL archives are pushed to all repositories when pgBackRest is set to use both a local and a S3-based repository
+- Silence expected error conditions when a pgBackRest repository is being initialized.
+- Deployments with `pgo-deployer` using the default file with `hostpathstorage` will now successfully deploy PostgreSQL clusters without any adjustments.
+- Add the `watch` permissions to the `pgo-deployer` ServiceAccount.
+- Ensure the PostgreSQL Operator can be uninstalled by adding `list` verb ClusterRole privileges to several Kubernetes objects.
+- Ensure `client-setup.sh` executes to completion if existing PostgreSQL Operator credentials exist that were created by a different installation method.
+- Ensure `client-setup.sh` works with when there is an existing `pgo` client in the install path.
+- Update the documentation to properly name `CCP_IMAGE_PULL_SECRET_MANIFEST` and `PGO_IMAGE_PULL_SECRET_MANIFEST` in the `pgo-deployer` configuration.
+- Bring up the correct number of pgBouncer replicas when `pgo update cluster --startup` is issued.
+- Fixed issue where `pgo scale` would not work after `pgo update cluster --shutdown` and `pgo update cluster --startup` were run.
+- Ensure `pgo scaledown` deletes external WAL volumes from the replica that is removed.
+- Several fixes for selecting default storage configurations and sizes when using the `pgo-deployer` container. These include #1, #4, and #8.
+- Do not consider non-running Pods as primary Pods when checking for multiple primaries (Reported by @djcooklup).
+- Fix race condition that could occur while `pgo upgrade` was running while a HA configuration map attempted to sync. (Reported by Paul Heinen @v3nturetheworld).
+- The custom setup example was updated to reflect the current state of bootstrapping the PostgreSQL container.
+- Silence "ConfigMap not found" error messages that occurred during PostgreSQL cluster initialization, as these were not real errors.
+- Fix an issue with controller processing, which could manifest in PostgreSQL clusters not being deleted.
+- Eliminate `gcc` from the `postgres-ha` and `pgadmin4` containers.