content for v1.4.0

docs/server/kubernetes-operator/v1.0.0/operations/database-deployment.md

@@ -380,11 +380,7 @@ kubectl apply -f cluster.yaml
 ## Three Node Secure Cluster (using LetsEncrypt)
 
 Using LetsEncrypt, or any publicly trusted certificate, in an operator-managed KurrentDB cluster
-is not supported.
-
-The recommended workaround is to combine [self-signed certificates within the cluster](
-#three-node-secure-cluster-using-self-signed-certificates) with an Ingress that does TLS
-termination using the LetsEncrypt certificate.
+is not supported in v1.0.0; please upgrade to v1.4.0.
 
 ## Viewing Deployments
 

docs/server/kubernetes-operator/v1.1.0/operations/database-deployment.md

@@ -445,11 +445,7 @@ kubectl apply -f cluster.yaml
 ## Three Node Secure Cluster (using LetsEncrypt)
 
 Using LetsEncrypt, or any publicly trusted certificate, in an operator-managed KurrentDB cluster
-is not supported.
-
-The recommended workaround is to combine [self-signed certificates within the cluster](
-#three-node-secure-cluster-using-self-signed-certificates) with an Ingress that does TLS
-termination using the LetsEncrypt certificate.
+is not supported in v1.0.0; please upgrade to v1.4.0.
 
 ## Deploying With Scheduling Constraints
 

docs/server/kubernetes-operator/v1.2.0/operations/database-deployment.md

@@ -445,11 +445,7 @@ kubectl apply -f cluster.yaml
 ## Three Node Secure Cluster (using LetsEncrypt)
 
 Using LetsEncrypt, or any publicly trusted certificate, in an operator-managed KurrentDB cluster
-is not supported.
-
-The recommended workaround is to combine [self-signed certificates within the cluster](
-#three-node-secure-cluster-using-self-signed-certificates) with an Ingress that does TLS
-termination using the LetsEncrypt certificate.
+is not supported in v1.0.0; please upgrade to v1.4.0.
 
 ## Deploying With Scheduling Constraints
 

docs/server/kubernetes-operator/v1.3.1/operations/database-deployment.md

@@ -441,11 +441,7 @@ kubectl apply -f cluster.yaml
 ## Three Node Secure Cluster (using LetsEncrypt)
 
 Using LetsEncrypt, or any publicly trusted certificate, in an operator-managed KurrentDB cluster
-is not supported.
-
-The recommended workaround is to combine [self-signed certificates within the cluster](
-#three-node-secure-cluster-using-self-signed-certificates) with an Ingress that does TLS
-termination using the LetsEncrypt certificate.
+is not supported in v1.0.0; please upgrade to v1.4.0.
 
 ## Deploying With Scheduling Constraints
 

docs/server/kubernetes-operator/v1.4.0/README.md

@@ -1,5 +1,5 @@
 ---
 # title is for breadcrumb and sidebar nav
-title: Kubernetes Operator v1.3.1
+title: Kubernetes Operator v1.4.0
 order: 1
 ---

docs/server/kubernetes-operator/v1.4.0/getting-started/README.md

@@ -23,41 +23,40 @@ Kubernetes is the modern enterprise standard for deploying containerized applica
 
 * Deploy single-node or multi-node clusters
 * Back up and restore clusters
+* Automate backups with a schedule and retention policies
 * Perform rolling upgrades and update configurations
 
-### New in 1.3.1
-
-* Fix/improve support for resizing KurrentDB clusters, including explicitly handling data safety,
-  minimizing downtime, and allowing the user to cancel a resize operation that is not progressing.
-  See [Updating Replica Count](../operations/modify-deployments.md#updating-replica-count) for details.
-* Support for custom labels and annotations on all child resources (StatefulSets, Pods,
-  LoadBalancers, etc).
-* Allow users to use public certificate authorities like LetsEncrypt without having to manually pass
-  the publicly trusted cert in a secret.
-* Allow manual overrides to the generated ConfigMap that is passed to KurrentDB.  Previously, if a
-  user manually altered the ConfigMap it would get immediately overwritten, whereas now it will
-  "stick" until the next time the KurrentDB resource is updated.
-* Fix a bug affecting the KurrentDBBackup behavior when cluster's fqdnTemplate met certain criteria.
-* Fix and clarified the `credentialsSecretName` behavior in the helm chart.  It is not normally
-  required at all, but in previous versions, it was generating warning events with the default
-  configuration.
-* Add a new `crds.keep` value to the helm chart.  With the default value of `true`, CRDs installed
-  by the helm chart will not be deleted by helm, which offers a layer of protection against
-  accidental data loss.  In earlier versions of the helm chart, or with `crds.keep=false`, a
-  transition from `crds.enabled=true` to `crds.enabled=false` would cause the deletion of the CRDs
-  and all KurrentDB and KurrentDBBackup objects across the cluster.
+### New in 1.4.0
+
+* Support configurable traffic strategies for each of server-server and client-server traffic.  This
+  enables the use of LetsEncrypt certificates without creating Ingresses, for example.  See
+  [Traffic Strategies][ts] for details.
+* Support backup scheduling and retention policies.  There is a new [KurrentDBBackupSchedule][bs]
+  CRD with a CronJob-like syntax.  There are also two mechanisms for configuring retention policies:
+  a `.keep` count on `KurrentDBBackupSchedule`, and a new `.ttl` on `KurrentDBBackup`.
+* Support standalone read-only replicas pointed at a remote cluster.  This enables advanced
+  topologies like a having your quorum nodes in one region and a read-only replica in a distant
+  region.  See [Deploying Standalone Read-Only Replicas][ror] for an example.
+* Support template strings in some extra metadata for child resources of the `KurrentDB` object.
+  This allows, for example, to annotate each of the automatically created LoadBalancers with unique
+  external-dns annotations.  See [KurrentDBExtraMetadataSpec][em] for details.
+
+[ts]: ../operations/advanced-networking.md#traffic-strategy-options
+[bs]: resource-types.md#kurrentdbbackupschedulespec
+[ror]: ../operations/database-deployment.md#deploying-standalone-read-only-replicas
+[em]: resource-types.md#kurrentdbextrametadataspec
 
 ## Supported KurrentDB Versions
 
 The Operator supports running the following major versions of KurrentDB:
 - v25.x
 - v24.x
-- v23.x
+- v23.10+
 
 ## Supported Hardware Architectures
 
 The Operator is packaged for the following hardware architectures:
-- x86_64
+- x86\_64
 - arm64
 
 ## Technical Support

docs/server/kubernetes-operator/v1.4.0/getting-started/installation.md

@@ -37,8 +37,9 @@ helm repo add kurrent-latest \
 The Operator uses Custom Resource Definitions (CRDs) to extend Kubernetes. You can install them automatically with Helm or manually.
 
 The following resource types are supported:
-- [KurrentDB](resource-types.md#kurrentdb)
-- [KurrentDBBackup](resource-types.md#kurrentdbbackup)
+- [KurrentDB](resource-types.md#kurrentdbspec)
+- [KurrentDBBackup](resource-types.md#kurrentdbbackupspec)
+- [KurrentDBBackupSchedules](resource-types.md#kurrentdbbackupschedulesspec)
 
 Since CRDs are managed globally by Kubernetes, special care must be taken to install them.
 
@@ -52,7 +53,7 @@ If you prefer to install CRDs yourself:
 
 ```bash
 # Download the kurrentdb-operator Helm chart
-helm pull kurrent-latest/kurrentdb-operator --version 1.3.1 --untar
+helm pull kurrent-latest/kurrentdb-operator --version 1.4.0 --untar
 # Install the CRDs
 kubectl apply -f kurrentdb-operator/templates/crds
 ```
@@ -86,7 +87,7 @@ To deploy the Operator in this mode, run:
 
 ```bash
 helm install kurrentdb-operator kurrent-latest/kurrentdb-operator \
-  --version 1.3.1 \
+  --version 1.4.0 \
   --namespace kurrent \
   --create-namespace \
   --set crds.enabled=true \
@@ -121,7 +122,7 @@ To deploy the Operator in this mode, the following command can be used:
 
 ```bash
 helm install kurrentdb-operator kurrent-latest/kurrentdb-operator \
-  --version 1.3.1 \
+  --version 1.4.0 \
   --namespace kurrent \
   --create-namespace \
   --set crds.enabled=true \
@@ -160,7 +161,7 @@ The Operator deployment can be updated to adjust which namespaces are watched. F
 
 ```bash
 helm upgrade kurrentdb-operator kurrent-latest/kurrentdb-operator \
-  --version 1.3.1 \
+  --version 1.4.0 \
   --namespace kurrent \
   --reuse-values \
   --set operator.namespaces='{kurrent,foo,bar}'
@@ -204,5 +205,5 @@ helm upgrade kurrentdb-operator kurrentdb-operator-repo/kurrentdb-operator \
 Here's what these commands do:
 - Refresh the local Helm repository index
 - Locate an existing operator installation in namespace `kurrent`
-- Select the target upgrade version `{version}` e.g. `1.3.1`
+- Select the target upgrade version `{version}` e.g. `1.4.0`
 - Perform the upgrade, preserving values that were set during installation