manually-revised import

product_docs/docs/postgres_for_kubernetes/1/addons.mdx

@@ -420,7 +420,7 @@ Kasten is a very popular data protection tool for Kubernetes, enabling backup
 and restore, disaster recovery, and application mobility for Kubernetes
 applications. For more information, see the [Kasten
 website](https://www.kasten.io/) and the [Kasten by Veeam Implementation
-Guide](https://www.enterprisedb.com/docs/partner_docs/KastenbyVeeam/)
+Guide](/partner_docs/KastenbyVeeam/)
 
 In brief, to enable transparent integration with Kasten on an EDB Postgres for
 Kubernetes Cluster, you just need to add the `kasten` value to the
@@ -451,8 +451,8 @@ backup hooks through annotations and labels to that instance.
     `k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled`
 
 For further guidance on how to configure and use Kasten, see the Implementation Guide's
-[Configuration](https://www.enterprisedb.com/docs/partner_docs/KastenbyVeeam/04-ConfiguringVeeamKasten/) and
-[Using](https://www.enterprisedb.com/docs/partner_docs/KastenbyVeeam/05-UsingVeeamKasten/) sections.
+[Configuration](/partner_docs/KastenbyVeeam/04-ConfiguringVeeamKasten/) and
+[Using](/partner_docs/KastenbyVeeam/05-UsingVeeamKasten/) sections.
 
 ### Limitations
 

product_docs/docs/postgres_for_kubernetes/1/architecture.mdx

@@ -238,7 +238,7 @@ EDB Postgres for Kubernetes recommends using the `node-role.kubernetes.io/postgr
 To assign the `postgres` taint to a node, use the following command:
 
 ```sh
-kubectl taint node <NODE-NAME> node-role.kubernetes.io/postgres=:noSchedule
+kubectl taint node <NODE-NAME> node-role.kubernetes.io/postgres=:NoSchedule
 ```
 
 To ensure that a `Cluster` resource is scheduled on a node with a `postgres` taint, you must correctly configure the `.spec.affinity.tolerations` stanza in your manifests.

product_docs/docs/postgres_for_kubernetes/1/before_you_start.mdx

@@ -132,7 +132,7 @@ Superuser
 PVC group
 : A PVC group in EDB Postgres for Kubernetes' terminology is a group of related PVCs
   belonging to the same PostgreSQL instance, namely the main volume containing
-  the PGDATA (`storage`) and the volume for WALs (`walStorage`).|
+  the PGDATA (`storage`) and the volume for WALs (`walStorage`).
 
 ## Cloud terminology
 

product_docs/docs/postgres_for_kubernetes/1/bootstrap.mdx

@@ -545,7 +545,7 @@ file on the source PostgreSQL instance:
 host replication streaming_replica all md5
 ```
 
-The following manifest creates a new PostgreSQL 16.4 cluster,
+The following manifest creates a new PostgreSQL 17.0 cluster,
 called `target-db`, using the `pg_basebackup` bootstrap method
 to clone an external PostgreSQL cluster defined as `source-db`
 (in the `externalClusters` array). As you can see, the `source-db`
@@ -560,7 +560,7 @@ metadata:
   name: target-db
 spec:
   instances: 3
-  imageName: quay.io/enterprisedb/postgresql:16.4
+  imageName: quay.io/enterprisedb/postgresql:17.0
 
   bootstrap:
     pg_basebackup:
@@ -580,7 +580,7 @@ spec:
 ```
 
 All the requirements must be met for the clone operation to work, including
-the same PostgreSQL version (in our case 16.4).
+the same PostgreSQL version (in our case 17.0).
 
 #### TLS certificate authentication
 
@@ -595,7 +595,7 @@ in the same Kubernetes cluster.
     This example can be easily adapted to cover an instance that resides
     outside the Kubernetes cluster.
 
-The manifest defines a new PostgreSQL 16.4 cluster called `cluster-clone-tls`,
+The manifest defines a new PostgreSQL 17.0 cluster called `cluster-clone-tls`,
 which is bootstrapped using the `pg_basebackup` method from the `cluster-example`
 external cluster. The host is identified by the read/write service
 in the same cluster, while the `streaming_replica` user is authenticated
@@ -610,7 +610,7 @@ metadata:
   name: cluster-clone-tls
 spec:
   instances: 3
-  imageName: quay.io/enterprisedb/postgresql:16.4
+  imageName: quay.io/enterprisedb/postgresql:17.0
 
   bootstrap:
     pg_basebackup:

product_docs/docs/postgres_for_kubernetes/1/certificates.mdx

@@ -35,10 +35,23 @@ generated outside CNP.
     names in user-provided certificates for the `<cluster>-rw` service used for
     communication within the cluster.
 
-## Operator-managed mode
-
-By default, the operator generates a single CA and uses it for both client and
-server certificates, which are then managed and renewed automatically.
+## Operator-Managed Mode
+
+By default, the operator automatically generates a single Certificate Authority
+(CA) to issue both client and server certificates. These certificates are
+managed continuously by the operator, with automatic renewal 7 days before
+expiration (within a 90-day validity period).
+
+!!! Info
+    You can adjust this default behavior by configuring the
+    `CERTIFICATE_DURATION` and `EXPIRING_CHECK_THRESHOLD` environment variables.
+    For detailed guidance, refer to the [Operator Configuration](operator_conf.md).
+
+!!! Important
+    Certificate renewal does not cause any downtime for the PostgreSQL server,
+    as a simple reload operation is sufficient. However, any user-managed
+    certificates not controlled by EDB Postgres for Kubernetes must be re-issued following the
+    renewal process.
 
 ### Server certificates
 

product_docs/docs/postgres_for_kubernetes/1/container_images.mdx

@@ -24,6 +24,7 @@ with the following requirements:
 -   PGAudit extension installed (optional - only if PGAudit is required
     in the deployed clusters)
 -   Appropriate locale settings
+-   `du` (optional, for `kubectl cnp status`)
 
 !!! Important
     Only [PostgreSQL versions supported by the PGDG](https://postgresql.org/) are allowed.

product_docs/docs/postgres_for_kubernetes/1/declarative_hibernation.mdx

@@ -61,7 +61,7 @@ $ kubectl cnp status <cluster-name>
 Cluster Summary
 Name:              cluster-example
 Namespace:         default
-PostgreSQL Image:  quay.io/enterprisedb/postgresql:16.4
+PostgreSQL Image:  quay.io/enterprisedb/postgresql:17.0
 Primary instance:  cluster-example-2
 Status:            Cluster in healthy state 
 Instances:         3

product_docs/docs/postgres_for_kubernetes/1/evaluation.mdx

@@ -21,7 +21,7 @@ There are two ways to obtain the EDB Postgres Advanced Server image for evaluati
 
 ### EDB Image Repository
 
-You can use EDB Postgres for Kubernetes with EDB Postgres Advanced Server. You can access the image by obtaining a repository access token to EDB’s image repositories.
+You can use EDB Postgres for Kubernetes with EDB Postgres Advanced Server. You can access the image by obtaining a repository access token to EDB's image repositories.
 
 ### Obtaining your access token
 
@@ -38,7 +38,7 @@ You can then use EDB Postgres Advanced Server by setting in the `spec` section o
 -   `imageName` to point to the quay.io/enterprisedb/edb-postgres-advanced repository  
 -   `licenseKey` to your license key (in the form of a string)
 
-To see how `imageName` and `licenseKey` is set, refer to the [cluster-full-example](https://www.enterprisedb.com/docs/postgres_for_kubernetes/latest/samples/cluster-example-full.yaml) file from the [configuration samples](https://www.enterprisedb.com/docs/postgres_for_kubernetes/latest/samples/) section.
+To see how `imageName` and `licenseKey` is set, refer to the [cluster-full-example](/postgres_for_kubernetes/latest/samples/cluster-example-full.yaml) file from the [configuration samples](/postgres_for_kubernetes/latest/samples/) section.
 
 ## Further Information
 

product_docs/docs/postgres_for_kubernetes/1/image_catalog.mdx

@@ -35,7 +35,7 @@ spec:
     - major: 15
       image: quay.io/enterprisedb/postgresql:15.6
     - major: 16
-      image: quay.io/enterprisedb/postgresql:16.4
+      image: quay.io/enterprisedb/postgresql:17.0
 ```
 
 **Example of a Cluster-Wide Catalog using `ClusterImageCatalog` Resource:**
@@ -50,7 +50,7 @@ spec:
     - major: 15
       image: quay.io/enterprisedb/postgresql:15.6
     - major: 16
-      image: quay.io/enterprisedb/postgresql:16.4
+      image: quay.io/enterprisedb/postgresql:17.0
 ```
 
 A `Cluster` resource has the flexibility to reference either an `ImageCatalog`

product_docs/docs/postgres_for_kubernetes/1/index.mdx

@@ -106,11 +106,9 @@ EDB Postgres for Kubernetes was made generally available on February 4, 2021. Ea
 ## Features unique to EDB Postgres of Kubernetes
 
 -   [Long Term Support](#long-term-support)
--   Red Hat certified operator for OpenShift
 -   Support on IBM Power and z/Linux through partnership with IBM
--   [Oracle compatibility](https://www.enterprisedb.com/docs/epas/latest/fundamentals/epas_fundamentals/epas_compat_ora_dev_guide/) through EDB Postgres Advanced Sever
--   [Transparent Data Encryption (TDE)](https://www.enterprisedb.com/docs/tde/latest/) through EDB Postgres Advanced Server
--   EDB Postgres for Kubernetes Plugin
+-   [Oracle compatibility](/epas/latest/fundamentals/epas_fundamentals/epas_compat_ora_dev_guide/) through EDB Postgres Advanced Sever
+-   [Transparent Data Encryption (TDE)](/tde/latest/) through EDB Postgres Advanced Server
 -   Cold backup support with Kasten and Velero/OADP
 -   Generic adapter for third-party Kubernetes backup tools
 
@@ -176,7 +174,7 @@ format for the following platforms: `linux/amd64`, `linux/arm64`, `linux/ppc64le
 
 The following versions of Postgres are currently supported:
 
--   PostgreSQL: 12 - 16
+-   PostgreSQL: 12 - 17
 -   EDB Postgres Advanced: 12 - 16
 -   EDB Postgres Extended: 12 - 16
 

product_docs/docs/postgres_for_kubernetes/1/installation_upgrade.mdx

@@ -23,12 +23,12 @@ The operator can be installed using the provided [Helm chart](https://github.com
 The operator can be installed like any other resource in Kubernetes,
 through a YAML manifest applied via `kubectl`.
 
-You can install the [latest operator manifest](https://get.enterprisedb.io/cnp/postgresql-operator-1.24.0.yaml)
+You can install the [latest operator manifest](https://get.enterprisedb.io/cnp/postgresql-operator-1.24.1.yaml)
 for this minor release as follows:
 
 ```sh
 kubectl apply --server-side -f \
-  https://get.enterprisedb.io/cnp/postgresql-operator-1.24.0.yaml
+  https://get.enterprisedb.io/cnp/postgresql-operator-1.24.1.yaml
 ```
 
 You can verify that with:
@@ -66,35 +66,6 @@ for a more comprehensive example.
     one of the allowed ones, or open the webhooks' port (`9443`) on the
     firewall.
 
-### Testing the latest development snapshot
-
-If you want to test or evaluate the latest development snapshot of
-EDB Postgres for Kubernetes before the next official patch release, you can download the
-manifests from the
-[`cloudnative-pg/artifacts`](https://github.com/cloudnative-pg/artifacts)
-which provides easy access to the current trunk (main) as well as to each
-supported release.
-
-For example, you can install the latest snapshot of the operator with:
-
-```sh
-curl -sSfL \
-  https://raw.githubusercontent.com/cloudnative-pg/artifacts/release-1.24/manifests/operator-manifest.yaml | \
-  kubectl apply --server-side -f -
-```
-
-If you are instead looking for the latest snapshot of the operator for this
-specific minor release, you can just run:
-
-```sh
-curl -sSfL \
-  https://raw.githubusercontent.com/cloudnative-pg/artifacts/main/manifests/operator-manifest.yaml | \
-  kubectl apply --server-side -f -
-```
-
-!!! Important
-    Snapshots are not supported by the EDB Postgres for Kubernetes Community, and are not
-    intended for use in production.
 
 ## Details about the deployment
 
@@ -235,12 +206,9 @@ When versions are not directly upgradable, the old version needs to be
 removed before installing the new one. This won't affect user data but
 only the operator itself.
 
-### Upgrading to 1.24.0 or 1.23.4
 
-!!! Important
-    We encourage all existing users of EDB Postgres for Kubernetes to upgrade to version
-    1.24.0 or at least to the latest stable version of the minor release you are
-    currently using (namely 1.23.4).
+
+### Upgrading to 1.24 from a previous minor version
 
 !!! Warning
     Every time you are upgrading to a higher minor release, make sure you

product_docs/docs/postgres_for_kubernetes/1/instance_manager.mdx

@@ -105,7 +105,7 @@ Please refer to the ["Failover" section](failover.md) for details.
 ## Disk Full Failure
 
 Storage exhaustion is a well known issue for PostgreSQL clusters.
-The [PostgreSQL documentation](https://www.postgresql.org/docs/current/disk-full.html)
+The [PostgreSQL documentation](https://www.postgresql.org/docs/current/diskusage.html#DISK-FULL)
 highlights the possible failure scenarios and the importance of monitoring disk
 usage to prevent it from becoming full.
 

product_docs/docs/postgres_for_kubernetes/1/iron-bank.mdx

@@ -45,7 +45,7 @@ example using Docker:
 For installation, you will need a deployment manifest that points to your Iron
 Bank image.
 You can take the deployment manifest from the
-[installation instructions for EDB PG4K](https://www.enterprisedb.com/docs/postgres_for_kubernetes/latest/installation_upgrade/).
+[installation instructions for EDB PG4K](/postgres_for_kubernetes/latest/installation_upgrade/).
 For example, for the 1.22.0 release, the manifest is available at
 `https://get.enterprisedb.io/cnp/postgresql-operator-1.22.0.yaml`. \\
 There are a couple of places where you will need to set the image path for the
@@ -89,4 +89,4 @@ site, and from there, re-tag and publish it to a local registry, or push it
 directly to your Kubernetes nodes.
 
 Once you have this in place, you can apply your manifest normally with
-`kubectl apply -f`, as described in the [installation instructions](https://www.enterprisedb.com/docs/postgres_for_kubernetes/latest/installation_upgrade/).
+`kubectl apply -f`, as described in the [installation instructions](/postgres_for_kubernetes/latest/installation_upgrade/).