Skip to content

Commit cfd8eaf

Browse files
author
Jonathan S. Katz
committed
Add draft release notes for 4.5.0
This makes it clearer what is coming in 4.5.0
1 parent 64b7ce9 commit cfd8eaf

File tree

2 files changed

+154
-0
lines changed

2 files changed

+154
-0
lines changed

‎docs/content/Configuration/compatibility.md‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,12 @@ version dependencies between the two projects. Below are the operator releases a
1212

1313
| Operator Release | Container Release | Postgres | PgBackrest Version
1414
|:----------|:-------------|:------------|:--------------
15+
| 4.5.0 | 4.5.0 | 12.4 | 2.28 |
16+
|||11.9|2.27|
17+
|||10.14|2.27|
18+
|||9.6.19|2.27|
19+
|||9.5.23|2.27|
20+
||||
1521
| 4.4.1 | 4.4.1 | 12.4 | 2.27 |
1622
|||11.9|2.27|
1723
|||10.14|2.27|

‎docs/content/releases/4.5.0.md‎

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
---
2+
title: "4.5.0"
3+
date:
4+
draft: false
5+
weight: 70
6+
---
7+
8+
Crunchy Data announces the release of the PostgreSQL Operator 4.5.0 on September XX, 2020.
9+
10+
The PostgreSQL Operator is released in conjunction with the [Crunchy Container Suite](https://github.com/CrunchyData/crunchy-containers/).
11+
12+
The PostgreSQL Operator 4.5.0 release includes the following software versions upgrades:
13+
14+
- [pgBackRest](https://pgbackrest.org/) is now at version 2.28.
15+
- [postgres\_exporter](https://github.com/wrouesnel/postgres_exporter) is now at version 0.8.0
16+
- [pgMonitor](https://github.com/CrunchyData/pgmonitor) support is now at 4.4
17+
- [pgnodemx](https://github.com/CrunchyData/pgnodemx) is now at version 1.0.1
18+
19+
Additionally, PostgreSQL Operator 4.5.0 introduces support for the CentOS 8 and UBI 8 base container images. In addition to using the newer operating systems, this enables support for TLS 1.3 when connecting to PostgreSQL. This release also moves to building the containers using [Buildah](https://buildah.io/) 1.14.9 and above, and supports Go 1.15.
20+
21+
The monitoring stack for the PostgreSQL Operator has shifted to use upstream components as opposed to repackaging them. These are specified as part of the [PostgreSQL Operator Installer](https://access.crunchydata.com/documentation/postgres-operator/latest/installation/postgres-operator/). We have tested this release with the following versions of each component:
22+
23+
- Prometheus: 2.20.0
24+
- Grafana: 6.7.4
25+
- Alertmanager: 0.21.0
26+
27+
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+.
28+
29+
## Major Features
30+
31+
### [PostgreSQL Operator Monitoring](https://crunchydata.github.io/postgres-operator/latest/architecture/monitoring/)
32+
33+
![PostgreSQL Operator Monitoring](https://crunchydata.github.io/postgres-operator/latest/images/postgresql-monitoring.png)
34+
35+
This release makes several changes to the PostgreSQL Operator Monitoring solution, notably making it much easier to set up a turnkey PostgreSQL monitoring solution with the PostgreSQL Operator using the open source [pgMonitor](https://github.com/CrunchyData/pgmonitor) project.
36+
37+
pgMonitor combines insightful queries for PostgreSQL with several proven tools for statistics collection, data visualization, and alerting to allow one to deploy a turnkey monitoring solution for PostgreSQL. The pgMonitor 4.4 release added support for Kubernetes environments, particularly with the [pgnodemx](https://github.com/CrunchyData/pgnodemx) that allows one to get host-like information from the Kubernetes Pod a PostgreSQL instance is deployed within.
38+
39+
PostgreSQL Operator 4.5 integrates with pgMonitor to take advantage of its Kubernetes support, and provides the following visualized metrics out-of-the-box:
40+
41+
- Pod metrics (CPU, Memory, Disk activity)
42+
- PostgreSQL utilization (Database activity, database size, WAL size, replication lag)
43+
- Backup information, including last backup and backup size
44+
- Network utilization (traffic, saturation, latency)
45+
- Alerts (uptime et al.)
46+
47+
More metrics and visualizations will be added in future releases. You can further customize these to meet the needs for your enviornment.
48+
49+
PostgreSQL Operator 4.5 uses the upstream packages for Prometheus, Grafana, and Alertmanager. Those using earlier versions of monitoring provided with the PostgreSQL Operator will need to switch to those packages. The tested versions of these packages for PostgreSQL Operator 4.5 include:
50+
51+
- Prometheus (2.20.0)
52+
- Grafana (6.7.4)
53+
- Alertmanager (0.21.0)
54+
55+
You can find out how to [install PostgreSQL Operator Monitoring](https://access.crunchydata.com/documentation/postgres-operator/latest/latest/installation/metrics/) in the installation section:
56+
57+
[https://access.crunchydata.com/documentation/postgres-operator/latest/latest/installation/metrics/](https://access.crunchydata.com/documentation/postgres-operator/latest/latest/installation/metrics/)
58+
59+
More information on how the monitoring systems works is available at:
60+
61+
[https://crunchydata.github.io/postgres-operator/latest/architecture/monitoring/](https://crunchydata.github.io/postgres-operator/latest/architecture/monitoring/)
62+
63+
### Customizing pgBackRest via ConfigMap
64+
65+
[pgBackRest](https://pgbackrest.org/) powers the [disaster recovery](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/disaster-recovery/) capabilities of PostgreSQL clusters deployed by the PostgreSQL Operator. While the PostgreSQL Operator provides many toggles to customize a pgBackRest configuration, it can be easier to do so directly using the [pgBackRest configuration file format](https://pgbackrest.org/configuration.html).
66+
67+
This release adds the ability to specify the pgBackRest configuration from either a ConfigMap or Secret by using the `pgo create cluster --pgbackrest-custom-config` flag, or by setting the `BackrestConfig` attributes in the `pgcluster` CRD. Setting this allows any pgBackRest resource (Pod, Job etc.) to leverage this custom configuration.
68+
69+
Note that some settings will be overriden by the PostgreSQL Operator regardless of the settings of a customized pgBackRest configuration file due to the nature of how the PostgreSQL instances managed by the Operator access pgBackRest. However, these are typically not the settings that one wants to customize.
70+
71+
### Apply Custom Annotations to Managed Deployments
72+
73+
It is now possible to add custom annotations to the Deployments that the PostgreSQL Operator manages. These include:
74+
75+
- PostgreSQL instances
76+
- pgBackRest repositories
77+
- pgBouncer instances
78+
79+
Annotations are applied on a per-cluster basis, and can be set either for all the managed Deployments within a cluster or individual Deployment groups. The annotations can be set as part of the `Annotations` section of the pgcluster specification.
80+
81+
This also introduces several flags to the [`pgo` client](https://access.crunchydata.com/documentation/postgres-operator/latest/pgo-client/) that help with the management of the annotations. These flags are available on `pgo create cluster` and `pgo update cluster` commands and include:
82+
83+
- `--annotation` - apply annotations on all managed Deployments
84+
- `--annotation-postgres` - applies annotations on all managed PostgreSQL Deployments
85+
- `--annotation-pgbackrest` - applies annotations on all managed pgBackRest Deployments
86+
- `--annotation-pgbouncer` - applies annotations on all managed pgBouncer Deployments
87+
88+
These flags work similarly to how one manages annotations and labels from `kubectl`. To add an annotation, one follows the format:
89+
90+
`--annotation=key=value`
91+
92+
To remove an annotation, one follows the format:
93+
94+
`--annotation=key-`
95+
96+
## Breaking Changes
97+
98+
- The `crunchy-collect` container, used for metrics collection is renamed to `crunchy-postgres-exporter`
99+
- The `backrest-restore-<fromClusterName>-to-<toPVC>` pgtask has been renamed to `backrest-restore-<clusterName>`. Additionally, the following parameters no longer need to be specified for the pgtask:
100+
- pgbackrest-stanza
101+
- pgbackrest-db-path
102+
- pgbackrest-repo-path
103+
- pgbackrest-repo-host
104+
- backrest-s3-verify-tls
105+
- When a restore job completes, it now emits the message `restored Primary created` instead of `restored PVC created`.
106+
- The `toPVC` parameter has been removed from the restore request endpoint.
107+
- Restore jobs using `pg_restore` no longer have `from-<pvcName>` in their names.
108+
- The `pgo-backrest-restore` container has been retired.
109+
- The `pgo load` command has been removed. This also retires the `pgo-load` container.
110+
- The `crunchy-prometheus` and `crunchy-grafana` containers are now removed. Please use the corresponding upstream containers.
111+
112+
## Features
113+
114+
- The metrics collection container now has configurable resources. This can be set as part of the custom resource workflow as well as from the `pgo` client when using the following command-line arguments:
115+
- CPU resource requests:
116+
- `pgo create cluster --exporter-cpu`
117+
- `pgo update cluster --exporter-cpu`
118+
- CPU resource limits:
119+
- `pgo create cluster --exporter-cpu-limit`
120+
- `pgo update cluster --exporter-cpu-limit`
121+
- Memory resource requests:
122+
- `pgo create cluster --exporter-memory`
123+
- `pgo update cluster --exporter-memory`
124+
- Memory resource limits:
125+
- `pgo create cluster --exporter-memory-limit`
126+
- `pgo update cluster --exporter-memory-limit`
127+
- Support for TLS 1.3 connections to PostgreSQL when using the UBI 8 and CentOS 8 containers
128+
- Added support for the [`pgnodemx`](https://github.com/CrunchyData/pgnodemx) extension which makes container-level metrics (CPU, memory, storage utilization) available via a PostgreSQL-based interface.
129+
130+
## Changes
131+
132+
- The [`pgo restore`](https://access.crunchydata.com/documentation/postgres-operator/latest/pgo-client/reference/pgo_restore/) methodology is changed to mirror the approach taken by `pgo create cluster --restore-from` that was introduced in the previous release. While `pgo restore` will still perform a ["restore in-place"](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/disaster-recovery/#restores), it will now take the following actions:
133+
- Any existing persistent volume claims (PVCs) in a cluster removed.
134+
- New PVCs are initialized and the data from the PostgreSQL cluster is restored based on the parameters specified in `pgo restore`.
135+
- Any customizations for the cluster (e.g. custom PostgreSQL configuration) will be available.
136+
- This also fixes several bugs that were reported with the `pgo restore` functionality, some of which are captured further down in these release notes.
137+
- The [Downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) is now available to PostgreSQL instances.
138+
139+
## Fixes
140+
141+
- Ensure that if a PostgreSQL cluster is recreated from a PVC with existing data that it will apply any custom PostgreSQL configuration settings that are specified.
142+
- Fixed issues with PostgreSQL replica Pods not becoming ready after running `pgo restore`. This fix is a result of the change in methodology for how a restore occurs.
143+
- The pgBackRest URI style defaults to `host` if it is not set.
144+
- pgBackRest commands can now be executed even if there are multiple pgBackRest Pods available in a Deployment, so long as there is only one "running" pgBackRest Pod.
145+
- Ensure pgBackRest S3 Secrets can be upgraded from PostgreSQL Operator 4.3.
146+
- pgBadger now has a default memory limit of 64Mi, which should help avoid a visit from the OOM killer.
147+
- Fix `pgo label` when applying multiple labels at once.
148+
- Fix `pgo create pgorole` so that the expression `--permissions=*` works.

0 commit comments

Comments
 (0)