chore( cluster): Fix a bunch of typos and incorrect docs

.github/actions/deploy-cluster/action.yml

@@ -13,7 +13,7 @@ runs:
       env:
         NAMESPACE: ${{ inputs.namespace }}
       run: |
-        cat <<EOF | kubectl apply -f -
+        cat <<EOF | kubectl apply --server-side --validate=strict -f -
         # Example of PostgreSQL cluster
         apiVersion: postgresql.cnpg.io/v1
         kind: Cluster

.github/actions/deploy-operator/action.yml

@@ -17,13 +17,12 @@ runs:
       env:
         NAMESPACE: ${{ inputs.namespace }}
         CLUSTER_WIDE: ${{ inputs.cluster-wide }}
-      run:
-        helm dependency update charts/cloudnative-pg
-
-        helm upgrade
-        --install 
-        --namespace $NAMESPACE
-        --create-namespace
-        --set config.clusterWide=$CLUSTER_WIDE
-        --wait
-        cnpg charts/cloudnative-pg
+      run: |
+        helm repo add cnpg https://cloudnative-pg.github.io/charts
+        helm upgrade \
+          --install \
+          --namespace $NAMESPACE \
+          --create-namespace \
+          --set config.clusterWide=$CLUSTER_WIDE \
+          --wait \
+          cnpg cnpg/cloudnative-pg

.gitignore

@@ -16,8 +16,11 @@ charts/**/charts/*.tgz
 # Output of the go coverage tool, specifically when used with LiteIDE
 *.out
 
-# editor and IDE paraphernalia
+# Editor and IDE paraphernalia
 .idea
 *.swp
 *.swo
 *~
+
+# macOS
+.DS_Store

LICENSE

@@ -1,4 +1,3 @@
-
                                  Apache License
                            Version 2.0, January 2004
                         http://www.apache.org/licenses/

charts/cluster/README.md

@@ -68,7 +68,7 @@ Depending on the type the chart will use a different Docker image and fill in so
 
 The chart has three modes of operation. These are configured via the `mode` parameter:
 * `standalone` - Creates new or updates an existing CNPG cluster. This is the default mode.
-* `replica` - Creates a replica cluster from an existing CNPG cluster. **_Note_ that this mode is not yet supported.**
+* `replica` - Creates a replica cluster from an existing CNPG cluster.
 * `recovery` - Recovers a CNPG cluster from a backup, object store or via pg_basebackup.
 
 ### Backup configuration
@@ -93,9 +93,9 @@ backups:
       backupOwnerReference: self
 ```
 
-Each backup adapter takes it's own set of parameters, listed in the [Configuration options](#Configuration-options) section
-below. Refer to the table for the full list of parameters and place the configuration under the appropriate key: `backup.s3`,
-`backup.azure`, or `backup.google`.
+Each backup adapter takes it's own set of parameters, listed in the [Configuration options](#Configuration-options)
+section. Refer to the table for the full list of parameters and place the configuration under the appropriate key: `backups.s3`,
+`backups.azure`, or `backups.google`.
 
 Recovery
 --------
@@ -106,7 +106,7 @@ Examples
 --------
 
 There are several configuration examples in the [examples](examples) directory. Refer to them for a basic setup and
-refer to  the [CloudNativePG Documentation](https://cloudnative-pg.io/documentation/current/) for more advanced configurations.
+refer to the [CloudNativePG Documentation](https://cloudnative-pg.io/documentation/current/) for more advanced configurations.
 
 ## Values
 

charts/cluster/README.md.gotmpl

@@ -76,7 +76,7 @@ Depending on the type the chart will use a different Docker image and fill in so
 
 The chart has three modes of operation. These are configured via the `mode` parameter:
 * `standalone` - Creates new or updates an existing CNPG cluster. This is the default mode.
-* `replica` - Creates a replica cluster from an existing CNPG cluster. **_Note_ that this mode is not yet supported.**
+* `replica` - Creates a replica cluster from an existing CNPG cluster.
 * `recovery` - Recovers a CNPG cluster from a backup, object store or via pg_basebackup.
 
 ### Backup configuration
@@ -101,9 +101,9 @@ backups:
       backupOwnerReference: self
 ```
 
-Each backup adapter takes it's own set of parameters, listed in the [Configuration options](#Configuration-options) section
-below. Refer to the table for the full list of parameters and place the configuration under the appropriate key: `backup.s3`,
-`backup.azure`, or `backup.google`.
+Each backup adapter takes it's own set of parameters, listed in the [Configuration options](#Configuration-options)
+section. Refer to the table for the full list of parameters and place the configuration under the appropriate key: `backups.s3`,
+`backups.azure`, or `backups.google`.
 
 
 Recovery
@@ -116,7 +116,7 @@ Examples
 --------
 
 There are several configuration examples in the [examples](examples) directory. Refer to them for a basic setup and
-refer to  the [CloudNativePG Documentation](https://cloudnative-pg.io/documentation/current/) for more advanced configurations.
+refer to the [CloudNativePG Documentation](https://cloudnative-pg.io/documentation/current/) for more advanced configurations.
 
 
 {{ template "chart.requirementsSection" . }}

charts/cluster/docs/Getting Started.md

@@ -4,14 +4,14 @@ The CNPG cluster chart follows a convention over configuration approach. This me
 CNPG setup with sensible defaults. However, you can override these defaults to create a more customized setup. Note that
 you still need to configure backups and monitoring separately. The chart will not install a Prometheus stack for you.
 
-_**Note,**_ that this is an opinionated chart. It does not support all configuration options that CNPG supports. If you
+_**Note**_ that this is an opinionated chart. It does not support all configuration options that CNPG supports. If you
 need a highly customized setup, you should manage your cluster via a Kubernetes CNPG cluster manifest instead of this chart.
 Refer to the [CNPG documentation](https://cloudnative-pg.io/documentation/current/) in that case.
 
 ## Installing the operator
 
-To begin, make sure you install the CNPG operator in you cluster. It can be installed via a Helm chart as shown below or
-ir can be installed via a Kubernetes manifest. For more information see the [CNPG documentation](https://cloudnative-pg.io/documentation/current/installation_upgrade/).
+To begin, make sure you install the CNPG operator in your cluster. It can be installed via a Helm chart as shown below or
+it can be installed via a Kubernetes manifest. For more information see the [CNPG documentation](https://cloudnative-pg.io/documentation/current/installation_upgrade/).
 
 ```console
 helm repo add cnpg https://cloudnative-pg.github.io/charts
@@ -39,12 +39,12 @@ Depending on the type the chart will use a different Docker image and fill in so
 The chart has three modes of operation. These are configured via the `mode` parameter. If this is your first cluster, you
 are likely looking for the `standalone` option.
 * `standalone` - Creates new or updates an existing CNPG cluster. This is the default mode.
-* `replica` - Creates a replica cluster from an existing CNPG cluster. **_Note_ that this mode is not yet supported.**
+* `replica` - Creates a replica cluster from an existing CNPG cluster.
 * `recovery` - Recovers a CNPG cluster from a backup, object store or via pg_basebackup.
 
 ### Backup configuration
 
-Most importantly you should configure your backup storage. 
+Most importantly you should configure your backup storage.
 
 CNPG implements disaster recovery via [Barman](https://pgbarman.org/). The following section configures the barman object
 store where backups will be stored. Barman performs backups of the cluster filesystem base backup and WALs. Both are
@@ -66,22 +66,22 @@ Additionally you can specify the following parameters:
         backupOwnerReference: self
   ```
 
-Each backup adapter takes it's own set of parameters, listed in the [Configuration options](../README.md#Configuration-options) section
-below. Refer to the table for the full list of parameters and place the configuration under the appropriate key: `backup.s3`,
-`backup.azure`, or `backup.google`.
+Each backup adapter takes it's own set of parameters, listed in the [Configuration options](../README.md#Configuration-options)
+section. Refer to the table for the full list of parameters and place the configuration under the appropriate key: `backups.s3`,
+`backups.azure`, or `backups.google`.
 
 ### Cluster configuration
 
 There are several important cluster options. Here are the most important ones:
 
 `cluster.instances` - The number of instances in the cluster. Defaults to `1`, but you should set this to `3` for production.
 `cluster.imageName` - This allows you to override the Docker image used for the cluster. The chart will choose a default
-  for you based on the setting you chose for `type`. If you need to run a configuration that is not supported, you can 
+  for you based on the setting you chose for `type`. If you need to run a configuration that is not supported, you can
   create your own Docker image. You can use the [postgres-containers](https://github.com/cloudnative-pg/postgres-containers)
   repository for a starting point.
   You will likely need to set your own repository access credentials via: `cluster.imagePullPolicy` and `cluster.imagePullSecrets`.
 `cluster.storage.size` - The size of the persistent volume claim for the cluster. Defaults to `8Gi`. Every instance will
-  have it's own persistent volume claim.
+  have its own persistent volume claim.
 `cluster.storage.storageClass` - The storage class to use for the persistent volume claim.
 `cluster.resources` - The resource limits and requests for the cluster. You are strongly advised to use the same values
   for both limits and requests to ensure a [Guaranteed QoS](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#guaranteed).
@@ -93,7 +93,7 @@ There are several important cluster options. Here are the most important ones:
   cluster:
     postgresql:
       max_connections: "200"
-      shared_buffers: "2GB"  
+      shared_buffers: "2GB"
   ```
 `cluster.initSQL` - Allows you to run custom SQL queries during the cluster initialization. This is useful for creating
 extensions, schemas and databases. Note that these are as a superuser.
@@ -103,4 +103,4 @@ For a full list - refer to the Helm chart [configuration options](../README.md#C
 ## Examples
 
 There are several configuration examples in the [examples](../examples) directory. Refer to them for a basic setup and
-refer to  the [CloudNativePG Documentation](https://cloudnative-pg.io/documentation/current/) for more advanced configurations.
+refer to the [CloudNativePG Documentation](https://cloudnative-pg.io/documentation/current/) for more advanced configurations.

charts/cluster/docs/Recovery.md

@@ -16,9 +16,9 @@ When performing a recovery you are strongly advised to use the same configuratio
 
 To begin, create a `values.yaml` that contains the following:
 
-1. Set `mode: recovery` to indicate that you want to perform bootstrap the new cluster from an existing one.
+1. Set `mode: recovery` to indicate that you want to bootstrap the new cluster from an existing one.
 2. Set the `recovery.method` to the type of recovery you want to perform.
-3. Set either the `recovery.backupName` or the Barman Object Store configuration - i.e. `recovery.provider` and appropriate S3, Azure or GCS configuration. In case of `pg_basebackup` complete the `recovery.pgBaseBackup` section. 
+3. Set either the `recovery.backupName` or the Barman Object Store configuration - i.e. `recovery.provider` and appropriate S3, Azure or GCS configuration. In case of `pg_basebackup` complete the `recovery.pgBaseBackup` section.
 4. Optionally set the `recovery.pitrTarget.time` in RFC3339 format to perform a point-in-time recovery (not applicable for `pgBaseBackup`).
 5. Retain the identical PostgreSQL version and configuration as the original cluster.
 6. Make sure you don't use the same backup section name as the original cluster. We advise you change the `path` within the storage location if you want to reuse the same storage location/bucket.

charts/cluster/docs/runbooks/CNPGClusterHighPhysicalReplicationLagWarning.md

@@ -6,7 +6,7 @@ The `CNPGClusterHighPhysicalReplicationLagWarning` alert is triggered when physi
 
 ## Impact
 
-High physical replication lag can cause the cluster replicas to become out of sync. Queries to the `-r` and `-ro` endpoints may return stale data. In the event of a failover, the data that has not yet been replicated from the primary to the replicas may be lost during failover..
+High physical replication lag can cause the cluster replicas to become out of sync. Queries to the `-r` and `-ro` endpoints may return stale data. In the event of a failover, the data that has not yet been replicated from the primary to the replicas may be lost during failover.
 
 ## Diagnosis
 
@@ -34,7 +34,7 @@ Inspect the disk IO statistics using the [CloudNativePG Grafana Dashboard](https
 
 Inspect the `Stat Activity` section of the [CloudNativePG Grafana Dashboard](https://grafana.com/grafana/dashboards/20417-cloudnativepg/).
 
-- Suboptimal PostgreSQL configuration, e.g. too `few max_wal_senders`. Set this to at least the number of cluster instances (default 10 is usually sufficient).
+- Suboptimal PostgreSQL configuration, e.g. too few `max_wal_senders`. Set this to at least the number of cluster instances (default 10 is usually sufficient).
 
 Inspect the `PostgreSQL Parameters` section of the [CloudNativePG Grafana Dashboard](https://grafana.com/grafana/dashboards/20417-cloudnativepg/).
 

charts/cluster/docs/runbooks/CNPGClusterPhysicalReplicationLag.md

@@ -175,7 +175,7 @@ SHOW max_replication_slots;
 
 ```bash
 # Check replication status
-kubectl exec -n <namespace> services/<cluster_name>-w -- psql -c "SELECT * FROM pg_stat_replication;"
+kubectl exec -n <namespace> services/<cluster_name>-rw -- psql -c "SELECT * FROM pg_stat_replication;"
 
 # Check resource usage
 kubectl top pods -n <namespace> -l cnpg.io/podRole=instance

charts/cluster/examples/custom-queries.yaml

@@ -15,7 +15,7 @@ cluster:
         metrics:
           - datname:
               usage: "LABEL"
-              description: "Name of the database database"
+              description: "Name of the database"
           - ratio:
               usage: GAUGE
               description: "Cache hit ratio"

charts/cluster/monitoring/metrics-clusters_postgresql_cnpg_io.yaml

@@ -86,7 +86,7 @@ spec:
                 primary: [status, currentPrimary]
 
         - name: "primary_failing_since_time"
-          help: "The timestamp when the primary was detected to be unhealthy This field is reported when .spec.failoverDelay is populated or during online upgrades"
+          help: "The timestamp when the primary was detected to be unhealthy. This field is reported when .spec.failoverDelay is populated or during online upgrades"
           each:
             type: Gauge
             gauge:

charts/cluster/prometheus_rules/cluster-low_disk_space-critical.yaml

@@ -7,15 +7,15 @@ annotations:
     CloudNativePG Cluster "{{ .namespace }}/{{ .cluster }}" is running extremely low on disk space. Check attached PVCs!
   runbook_url: https://github.com/cloudnative-pg/charts/blob/main/charts/cluster/docs/runbooks/CNPGClusterLowDiskSpaceCritical.md
 expr: |
-  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"})) > 0.9 OR
-  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"})) > 0.9 OR
+  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"})) * 100 > 90 OR
+  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"})) * 100 > 90 OR
   max(sum by (namespace,persistentvolumeclaim) (kubelet_volume_stats_used_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-tbs.*"})
       /
       sum by (namespace,persistentvolumeclaim) (kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-tbs.*"})
       *
       on(namespace, persistentvolumeclaim) group_left(volume)
       kube_pod_spec_volumes_persistentvolumeclaims_info{pod=~"{{ .podSelector }}"}
-  ) > 0.9
+  ) * 100 > 90
 for: 5m
 labels:
   severity: critical

charts/cluster/prometheus_rules/cluster-low_disk_space-warning.yaml

@@ -7,15 +7,15 @@ annotations:
     CloudNativePG Cluster "{{ .namespace }}/{{ .cluster }}" is running low on disk space. Check attached PVCs.
   runbook_url: https://github.com/cloudnative-pg/charts/blob/main/charts/cluster/docs/runbooks/CNPGClusterLowDiskSpaceWarning.md
 expr: |
-  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"})) > 0.7 OR
-  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"})) > 0.7 OR
+  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}"})) * 100 > 70 OR
+  max(max by(persistentvolumeclaim) (1 - kubelet_volume_stats_available_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"} / kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-wal"})) * 100 > 70 OR
   max(sum by (namespace,persistentvolumeclaim) (kubelet_volume_stats_used_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-tbs.*"})
       /
       sum by (namespace,persistentvolumeclaim) (kubelet_volume_stats_capacity_bytes{namespace="{{ .namespace }}", persistentvolumeclaim=~"{{ .podSelector }}-tbs.*"})
       *
       on(namespace, persistentvolumeclaim) group_left(volume)
       kube_pod_spec_volumes_persistentvolumeclaims_info{pod=~"{{ .podSelector }}"}
-  ) > 0.7
+  ) * 100 > 70
 for: 5m
 labels:
   severity: warning

charts/cluster/templates/_barman_object_store.tpl

@@ -6,7 +6,7 @@
 
 {{- if or (.scope.endpointCA.create) (.scope.endpointCA.name) }}
   endpointCA:
-    name: {{.scope.endpointCA.name }}
+    name: {{ .scope.endpointCA.name }}
     key: {{ .scope.endpointCA.key }}
 {{- end }}
 

charts/cluster/templates/ca-bundle.yaml

@@ -6,5 +6,4 @@ metadata:
   namespace: {{ include "cluster.namespace" . }}
 data:
   {{ .Values.backups.endpointCA.key | default "ca-bundle.crt" | quote }}: {{ .Values.backups.endpointCA.value }}
-
 {{- end }}

charts/cluster/test/pooler/chainsaw-test.yaml

@@ -1,6 +1,5 @@
 ##
-# This is a test that verifies that non-default configuration options are correctly propagated to the CNPG cluster.
-# P.S. This test is not designed to have a good running configuration, it is designed to test the configuration propagation!
+# This test verifies that PgBouncer poolers are correctly provisioned when configured via Helm values.
 apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata: