From b049a1a76658335053c5d2dc71e14efca14cac49 Mon Sep 17 00:00:00 2001 From: hfxia Date: Tue, 8 Sep 2026 02:18:22 -0400 Subject: [PATCH] docs: publish the 2.0.0 release, lifecycle, and platform compatibility 2.0.0 ships on 2026-09-08 with a two-year lifecycle and runs on Alauda Container Platform v4.2, v4.3, and v4.4. Replace the "not yet published" placeholders with the published facts: - lifecycle_policy: the version lifecycle timeline (end of full support 2027-09-30, end of maintenance 2028-09-30) plus the release, support-phase, and maintenance policy sections adapted from Alauda Cache Service E1; - release_notes: the compatibility and support matrix, the release date, and the removal of the pending-matrix caveat; - intro, installation, upgrade: current-release wording, the supported platform versions, and the v4.1 exclusion. 2.0.0 has no predecessor product version, so the upgrade procedure applies from the next 2.0.x release. Correct the 9.1 packaging claim. At tag v2.0.0 the canonical custom resource definition under config/crd/bases enumerates 9.1, and the delivered artifact is the OLM bundle generated from it. The stale chart copy under charts/ is referenced by neither the Makefile nor .build/build.yaml and is never installed, so five pages no longer attribute a packaging risk to it. The installed-schema verification step stays. Record the release facts and their evidence class in agent/SOURCE_POLICY.md, agent/CONTENT_AUDIT.md, and agent/ARCHITECTURE_FACTS.md; register the Full Support and Maintenance lifecycle terms in agent/TERMINOLOGY.md; and refresh llms.txt and llmstxt-state.json for the 15 files whose content changed since the index was last generated. --- agent/ARCHITECTURE_FACTS.md | 26 ++++++--- agent/CONTENT_AUDIT.md | 20 +++++-- agent/SOURCE_POLICY.md | 27 ++++++++- agent/TERMINOLOGY.md | 5 ++ docs/en/installation.mdx | 17 +++--- docs/en/intro.mdx | 14 +++-- docs/en/lifecycle_policy.mdx | 80 +++++++++++++++++++------- docs/en/limitations.mdx | 20 +++---- docs/en/release_notes.mdx | 29 +++++++--- docs/en/upgrade.mdx | 18 +++++- llms.txt | 12 ++-- llmstxt-state.json | 106 +++++++++++++++++------------------ 12 files changed, 245 insertions(+), 129 deletions(-) diff --git a/agent/ARCHITECTURE_FACTS.md b/agent/ARCHITECTURE_FACTS.md index 2c69848..dfdc01c 100644 --- a/agent/ARCHITECTURE_FACTS.md +++ b/agent/ARCHITECTURE_FACTS.md @@ -11,9 +11,11 @@ Evidence below refers to `valkey-operator` commit `20b3b6758fe6f5431e0e183e841d606b935c0853` (`origin/master`, 2026-08-11) plus the code-free product-naming commits up to `0135484d90d7bff19bd56fe5d08ed4657fc26df7`. +Both are ancestors of the shipped tag `v2.0.0`. The server-image facts refer to the `valkey` container-source commit -`7cb5874adf2c867dc2fc423435e33edc82226caa`, which is the commit suffix used by -that Operator baseline's 7.2, 8.1, and 9.1 image tags. +`7cb5874adf2c867dc2fc423435e33edc82226caa`. The `v2.0.0` 7.2, 8.1, and 9.1 image +tags carry the suffix `cf797832`, which is that commit plus one Alpine +base-image bump and no server change; it still builds 7.2.14, 8.1.9, and 9.1.1. ## Product contract @@ -27,7 +29,11 @@ that Operator baseline's 7.2, 8.1, and 9.1 image tags. writes `Valkey®` at the first usage of the mark in every listing field. The current wording is in `TERMINOLOGY.md`. The `valkey-operator` `master` branch still carries the superseded notice until that change is cherry-picked. -- The next major product release is `2.0.0`: `version:1`. +- The current product release is `2.0.0`: `version:1`, shipped as + `valkey-operator` tag `v2.0.0`. It was released on 2026-09-08 and runs on + Alauda Container Platform v4.2, v4.3, and v4.4. Release date, lifecycle dates, + and platform versions are product-owner requirements with no source-code + evidence; see `SOURCE_POLICY.md`. - The Operator image map selects Valkey server lines `7.2`, `8.1`, and `9.1`: `values.yaml:17-34`. These are the only supported versions in product docs. The pinned container source builds patch versions 7.2.14, 8.1.9, and 9.1.1. @@ -82,10 +88,16 @@ that Operator baseline's 7.2, 8.1, and 9.1 image tags. passage that tells a reader to inspect the replication credential must name the directive per line: `CONFIG GET primaryauth` returns an empty result on 7.2, which reads as "not set" while the credential is in fact held by `masterauth`. -- The Helm Chart CRD copy under `charts/valkey-operator/crds` is stale: it omits - 9.0 and 9.1, while the API type and canonical generated CRD include them. A - 2.0.0 release package must install the canonical schema so supported line 9.1 - passes admission. +- The Helm Chart CRD copy under `charts/valkey-operator/crds` is stale at tag + `v2.0.0`: it omits 9.0 and 9.1, while the API type and canonical generated CRD + include them. That copy is not the delivered artifact. The chart is an upstream + directory untouched since commit `d430d34`, referenced by neither the + `Makefile` nor `.build/build.yaml`; `.artifact/metadata.yaml` declares + `packageType: OperatorBundle`, and `make bundle` generates the bundle from + `config/manifests`, which pulls `config/crd/bases`. Product docs therefore + require installed-schema verification during release acceptance without + attributing the risk to the in-repo chart copy. The stale copy should still be + regenerated or removed in `valkey-operator`. - `replicasOfShard` is described in API comments as replica count, but builders use it as a StatefulSet Pod count. Documentation uses the implemented member-count behavior and preserves the literal field name in YAML. diff --git a/agent/CONTENT_AUDIT.md b/agent/CONTENT_AUDIT.md index 47e3c23..a9d4974 100644 --- a/agent/CONTENT_AUDIT.md +++ b/agent/CONTENT_AUDIT.md @@ -15,8 +15,12 @@ official command source as the surrounding section. ## Baselines and claim classes - **P — product requirement:** the product name Alauda Cache Service E2, - CLI-only operation, 2.0.0 as the next major release, supported server lines - 7.2/8.1/9.1, and no disaster recovery. + CLI-only operation, supported server lines 7.2/8.1/9.1, and no disaster + recovery. For the 2.0.0 release: release date 2026-09-08, a two-year lifecycle + ending full support on 2027-09-30 and maintenance on 2028-09-30, and support on + Alauda Container Platform v4.2, v4.3, and v4.4, and no predecessor product + version — the 2.x line only. These release facts are supplied by the product + owner and have no source-code evidence; `SOURCE_POLICY.md` records them. - **O — Operator implementation:** `valkey-operator` `origin/master` commit `20b3b6758fe6f5431e0e183e841d606b935c0853`, plus the code-free product-naming commits up to `0135484d90d7bff19bd56fe5d08ed4657fc26df7`. @@ -36,8 +40,8 @@ protocol semantics come from the official Valkey documentation. | Conflict | Evidence | Documentation resolution | | --- | --- | --- | -| Supported 9.1 versus stale packaged custom resource definition (CRD) | O: `api/rds/v1alpha1/valkey_types.go`, `config/crd/bases/rds.valkey.buf.red_valkeys.yaml`, and `charts/valkey-operator/crds/rds.valkey.buf.red_valkeys.yaml` | Declare the P support range, require installed-schema verification, and call a missing 9.1 enum a packaging defect. | -| Broader 8.0/9.0 source surface | O: high-level enum and image map; I: the pinned baseline builds only 7.2/8.1/9.1 and removed the 8.0/9.0 directories | The image map and P contract are narrower: only 7.2/8.1/9.1 are supported. | +| Supported 9.1 versus stale in-repo Helm Chart custom resource definition (CRD) copy | O: at tag `v2.0.0`, `api/rds/v1alpha1/valkey_types.go` and `config/crd/bases/rds.valkey.buf.red_valkeys.yaml` enumerate `7.2`/`8.0`/`8.1`/`9.0`/`9.1`, while `charts/valkey-operator/crds/rds.valkey.buf.red_valkeys.yaml` still enumerates `7.2`/`8.0`/`8.1`. The chart is an upstream artifact untouched since `d430d34`, is referenced by neither the `Makefile` nor `.build/build.yaml`, and is not the delivered package: `.artifact/metadata.yaml` declares `packageType: OperatorBundle`, and `make bundle` generates the bundle from `config/manifests`, which pulls `config/crd/bases`. | Declare the P support range and require installed-schema verification during release acceptance. Do not attribute the risk to the in-repo chart copy, which customers never install. | +| Broader 8.0/9.0 source surface | O: high-level enum and version map at tag `v2.0.0`, whose API comment records that no image is shipped for `8.0`/`9.0` and that without a `VALKEY_VERSION_MAP` entry they resolve to a bare `:8.0`/`:9.0` tag; I: the pinned baseline builds only 7.2/8.1/9.1 and removed the 8.0/9.0 directories | The version map and P contract are narrower: only 7.2/8.1/9.1 are supported; `8.0`/`9.0` are admissible but unshipped, untested, and usable only with a self-supplied image. | | Affinity schema versus builders | O: `api/core/types.go`; `internal/builder/clusterbuilder/statefulset.go`; `internal/builder/failoverbuilder/statefulset.go`; the Cluster ensure-resource actor preserving old StatefulSet affinity on update | Document exact builder behavior, mark Cluster custom affinity unreliable, and document that Cluster affinity changes reach only StatefulSets created afterward. | | Ignored `spec.storage.accessMode` | O: `api/core/types.go` default plus hard-coded `ReadWriteOnce` in the Cluster and Failover StatefulSet builders | Document the fixed `ReadWriteOnce` access mode and remove the access-mode choice from examples. | | Dead `retainAfterDeleted` and PVC ownership | O: value-copy owner-reference loop in both StatefulSet builders; no production PVC-deletion path | Document that PVCs always remain after deletion and require explicit cleanup. | @@ -56,6 +60,7 @@ protocol semantics come from the official Valkey documentation. | Page and section | Claim basis | | --- | --- | | `index.mdx` — navigation | Site tree only; this landing page contains no product capability claims. | +| `intro.mdx` — release and server versions | P: release date and supported Alauda Container Platform versions; O: high-level enum and version map. | | `intro.mdx` — reconciliation and capabilities | O: high-level controllers, topology actors, service/config/exporter/certificate builders, the credential-protection paths, and APIs; I: `CONFIG GET` redaction. | | `intro.mdx` — architectures and member counts | O: webhook/defaulting logic and StatefulSet replica assignments; U: [Cluster specification](https://valkey.io/topics/cluster-spec/), [replication](https://valkey.io/topics/replication/), and [Sentinel](https://valkey.io/topics/sentinel/). | | `intro.mdx` — responsibility boundary | P for unsupported backup, restore, disaster recovery, and Web Console; D from asynchronous replication and absence of protection controllers. | @@ -63,10 +68,13 @@ protocol semantics come from the official Valkey documentation. | `architecture.mdx` — Cluster | O: Cluster engine/builders; U: [Cluster specification](https://valkey.io/topics/cluster-spec/). | | `architecture.mdx` — Failover and Replica | O: high-level Failover generation, monitor selection, role-Service selectors; U: [replication](https://valkey.io/topics/replication/) and [Sentinel](https://valkey.io/topics/sentinel/). | | `architecture.mdx` — storage and status | O: storage API/builders and phase constants/controller assignments; D for failure-domain and data-protection cautions. | -| `installation.mdx` — prerequisites and defaults | O: Helm values/templates, CRDs, role-based access control, webhook, cert-manager, labels, and metrics Service. Distribution-specific commands remain explicitly unknown. | +| `installation.mdx` — prerequisites and defaults | P: supported Alauda Container Platform versions. O: Helm values/templates, CRDs, role-based access control, webhook, cert-manager, labels, and metrics Service. Registry, namespace, channel, and approval strategy remain distribution-specific and explicitly unknown. | +| `upgrade.mdx` — scope and platform compatibility | P: no predecessor product version, supported Alauda Container Platform versions, and the v4.1 exclusion. The product source-to-target upgrade path for later 2.0.x releases remains delegated to release metadata. | | `upgrade.mdx` — product upgrade | O: chart resources and API ownership; D from compatibility risk. Package commands and rollback contract are explicitly delegated to release metadata. | -| `lifecycle_policy.mdx` — version dimensions | P, O `version`/`values.yaml`, O status assignment, and I exact Dockerfile versions. Unpublished dates/matrix are marked unknown. | +| `lifecycle_policy.mdx` — timeline, compatibility, and support phases | P: release date 2026-09-08, end of full support 2027-09-30, end of maintenance 2028-09-30, and Alauda Container Platform v4.2/v4.3/v4.4. The phase, release, and maintenance wording follows the Alauda Cache Service E1 policy adapted to Valkey. | +| `lifecycle_policy.mdx` — version dimensions | P, O `version`/`values.yaml`, O status assignment, and I exact Dockerfile versions. | | `limitations.mdx` — unsupported and conflicting features | P plus repository-absence checks and each conflict in the release-level table above. | +| `release_notes.mdx` — compatibility and support matrix | P: release date and supported Alauda Container Platform versions; O: supported server lines. | | `release_notes.mdx` — 2.0.0 scope | P, O implemented feature paths including the credential-protection hardening, I exact patch baseline and `CONFIG GET` redaction, and the recorded source conflicts. | ## Feature guides diff --git a/agent/SOURCE_POLICY.md b/agent/SOURCE_POLICY.md index 9ebaf31..18650d4 100644 --- a/agent/SOURCE_POLICY.md +++ b/agent/SOURCE_POLICY.md @@ -26,8 +26,31 @@ For the initial 2.0.0 documentation, the inspected operator baseline is `origin/master` commit `20b3b6758fe6f5431e0e183e841d606b935c0853` from 2026-08-11, together with the product-naming commits up to `0135484d90d7bff19bd56fe5d08ed4657fc26df7`, which rename the display title to -Alauda Cache Service E2 and change no code. The server-image baseline pinned by -the Operator image tags is `7cb5874adf2c867dc2fc423435e33edc82226caa`. +Alauda Cache Service E2 and change no code. Both are ancestors of the shipped +`valkey-operator` tag `v2.0.0`. The server-image baseline pinned by the `v2.0.0` +Operator image tags is `cf797832`, which is `7cb5874adf2c867dc2fc423435e33edc82226caa` +plus one Alpine base-image bump and no server change; it builds Valkey 7.2.14, +8.1.9, and 9.1.1. The release candidate pinned in the `artifacts` registry, +`33812cb4`, is an ancestor of `v2.0.0` and differs from it only in the +`redis-exporter` image tag, so the version, schema, and server-image claims in +these documents hold for either commit. + +The following 2.0.0 release facts are product-owner requirements (evidence class +1). They have no source-code evidence and must not be inferred from the +repositories: + +- release date 2026-09-08; +- a two-year lifecycle: end of full support 2027-09-30, end of maintenance + 2028-09-30. Lifecycle dates are the release date plus one and two years, + rounded to the end of that month, following the Alauda Cache Service E1 + convention; +- supported platform versions Alauda Container Platform v4.2, v4.3, and v4.4; +- 2.0.0 has no predecessor product version. The documentation covers the 2.x + line only: `valkey-operator` `release-1.0`, `release-1.1`, `v1.0.0`, and + `v1.1.0` are out of scope, no 1.x row belongs in the lifecycle timeline, and no + 1.x-to-2.0.x upgrade path is documented. Because there is no predecessor, + 2.0.0 carries no fixed-issue, known-issue, or security-fix release-note + sections. Trademark wording does not come from the upstream project. `TERMINOLOGY.md` carries the notice and the symbol rule that the ACP component compliance rules diff --git a/agent/TERMINOLOGY.md b/agent/TERMINOLOGY.md index 1b9ca4b..033f861 100644 --- a/agent/TERMINOLOGY.md +++ b/agent/TERMINOLOGY.md @@ -29,6 +29,11 @@ i18n: | operator-owned resource | — | Child resource generated and reconciled from `Valkey`; users inspect it but change the owning high-level resource. | | large key | `valkey-cli --bigkeys` | Key whose size or collection cardinality creates workload-specific operational risk. Do not imply one universal size threshold. | | Web Console | — | Unsupported for this product; do not provide UI instructions. | +| Alauda Container Platform | — | The platform the product is installed on. Always write the full name; do not abbreviate it to ACP in published pages. | +| Full Support | — | First lifecycle phase of a minor version, from its release date to its end of full support. All bug fixes and security patches are delivered on that minor line. | +| Maintenance | — | Second lifecycle phase, from end of full support to end of maintenance. Only critical bug fixes and security patches are delivered; non-critical fixes are not backported. | +| end of full support | — | The date on which a minor version leaves Full Support. Lowercase in prose; title case only as a table column heading. | +| end of maintenance | — | The date after which a minor version is no longer supported. Lowercase in prose; title case only as a table column heading. | ## Trademark notice and symbol diff --git a/docs/en/installation.mdx b/docs/en/installation.mdx index ad4cf50..df746d1 100644 --- a/docs/en/installation.mdx +++ b/docs/en/installation.mdx @@ -16,6 +16,8 @@ are not defined by the Valkey Operator repository. ## Prerequisites +- Alauda Container Platform v4.2, v4.3, or v4.4. Alauda Cache Service E2 version + 2.0.0 is not supported on v4.1 or earlier; - a supported Kubernetes cluster and a `kubectl` context allowed to install the chart's cluster-scoped custom resource definitions (CRDs), admission webhooks, and role-based access control resources; @@ -25,10 +27,10 @@ are not defined by the Valkey Operator repository. `Issuer` or `ClusterIssuer` is also required when instance TLS is enabled; - a Prometheus-compatible scraper if exporter-sidecar metrics will be collected. -Obtain the release-specific platform compatibility matrix before production -installation. The documentation baseline does not define the supported Alauda -Container Platform versions, registry address, package namespace, channel, or -upgrade approval strategy. +The supported platform versions are listed in the +[compatibility and support matrix](./release_notes.mdx#compatibility-and-support-matrix). +The registry address, package namespace, channel, and upgrade approval strategy +are distribution-specific and come from the delivered release package. ## Preflight checks @@ -81,11 +83,8 @@ kubectl get crd \ users.valkey.buf.red ``` -The inspected 2.0.0 source contains two generated CRD copies that disagree on -the version enum: the API source and `config/crd/bases` include `9.1`, while the -Helm Chart CRD copy is stale. A release package that supports 9.1 must install a -CRD whose enum includes `7.2`, `8.1`, and `9.1`. Verify the installed schema -before creating an instance: +A 2.0.0 package must install a `Valkey` CRD whose version enum includes `7.2`, +`8.1`, and `9.1`. Verify the installed schema before creating an instance: ```bash kubectl explain valkey.spec.version diff --git a/docs/en/intro.mdx b/docs/en/intro.mdx index a90e568..265be1d 100644 --- a/docs/en/intro.mdx +++ b/docs/en/intro.mdx @@ -27,7 +27,9 @@ Console. Use `kubectl`, `valkey-cli`, and Kubernetes-native automation. ## Release and server versions -The next major product release is `2.0.0`. It supports these Valkey server lines: +The current product release is `2.0.0`, released on 2026-09-08. It runs on +Alauda Container Platform v4.2, v4.3, and v4.4, and supports these Valkey server +lines: | Supported line | Use in `spec.version` | | --- | --- | @@ -36,9 +38,13 @@ The next major product release is `2.0.0`. It supports these Valkey server lines | Valkey 9.1 | `"9.1"` | Do not use `8.0` or `9.0`, even if a compatibility enum in an installed custom -resource definition (CRD) accepts those values. The 2.0.0 Operator image map -selects only the 7.2, 8.1, and 9.1 server lines. A schema enum value for -another line does not establish product support. +resource definition (CRD) accepts those values. The 2.0.0 Operator version map +selects only the 7.2, 8.1, and 9.1 server lines, and no image is shipped for the +other two. A schema enum value for another line does not establish product +support. + +For support phases and end-of-support dates, see +[Lifecycle Policy](./lifecycle_policy.mdx). ## Architectures diff --git a/docs/en/lifecycle_policy.mdx b/docs/en/lifecycle_policy.mdx index e75f16e..7668acd 100644 --- a/docs/en/lifecycle_policy.mdx +++ b/docs/en/lifecycle_policy.mdx @@ -8,24 +8,56 @@ title: Lifecycle Policy # Lifecycle Policy -This page distinguishes published product facts from lifecycle information that -has not yet been established for Alauda Cache Service E2. +## Version lifecycle timeline -## Current release baseline +Below is the lifecycle schedule for released versions of Alauda Cache Service E2: -| Item | 2.0.0 status | -| --- | --- | -| Product release | Next major release | -| Supported Valkey server lines | `7.2`, `8.1`, and `9.1` | -| Release date | Not yet published | -| End of full support | Not yet published | -| End of maintenance | Not yet published | -| Alauda Container Platform compatibility matrix | Not yet published | +| Version | Release Date | End of Full Support | End of Maintenance | +|:--------|:-------------|:--------------------|:-------------------| +| v2.0.x | 2026-09-08 | 2027-09-30 | 2028-09-30 | + +Alauda Cache Service E2 2.0.x runs on Alauda Container Platform v4.2, v4.3, and +v4.4, and packages the Valkey 7.2, 8.1, and 9.1 server lines. The +[compatibility and support matrix](./release_notes.mdx#compatibility-and-support-matrix) +is the single source for that pairing. Do not derive product support dates from the upstream Valkey lifecycle. Product, Operator, server-image, and platform support are separate compatibility dimensions. +## Release policy + +* A new patch version of Alauda Cache Service E2 is released as needed to address + bugs and security vulnerabilities. Patch releases do not introduce new features. +* Minor and major version releases are driven by significant updates to the + underlying Valkey server, the implementation of new features, or emerging + security requirements. + +## Support phases + +Each minor version progresses through two support phases over its lifecycle: + +* **Full Support (Year 1)**: From the release date until the end of full support. + The version receives all bug fixes and security patches via patch releases on + the same minor line. +* **Maintenance (Year 2)**: From the end of full support until the end of + maintenance. The version receives only critical bug fixes and security patches; + non-critical fixes are not backported. + +After the end of maintenance, the version is no longer supported. Customers +should plan to upgrade to a supported version before this date. + +## Maintenance policy + +During a version's supported lifecycle, Alauda provides the following services: + +* **Upstream Patching**: We actively track official Valkey patch releases and + promptly deliver critical bug fixes and security vulnerability patches. +* **Security Updates**: We release security updates for the service operator + on-demand to address vulnerabilities and ensure stability. +* **Upgrade Assistance**: We provide dedicated support to help customers execute + smooth and seamless upgrades to newer versions. + ## Version dimensions | Version | What it controls | How to inspect it | @@ -41,16 +73,23 @@ procedure. ## Supported-version rule -The 2.0.0 Operator image map selects `7.2`, `8.1`, and `9.1`. The inspected -image-source baseline builds patch versions 7.2.14, 8.1.9, and 9.1.1. Exact -patch versions and digests still must be read from the delivered images. -Generated schema enum values for 8.0 or 9.0 are not a support commitment; do -not create or upgrade an instance to those values. +Alauda Cache Service E2 2.0.x supports the Valkey 7.2, 8.1, and 9.1 server +lines. The 2.0.0 image source builds patch versions 7.2.14, 8.1.9, and 9.1.1. +Exact patch versions and digests still must be read from the delivered images. + +The installed custom resource definition (CRD) also accepts `8.0` and `9.0`, +because those values remain in the API schema enum. No image is shipped for +either line: with no entry in the Operator version map they resolve to a bare +`:8.0` or `:9.0` tag, so they are usable only with a self-supplied image and are +neither supported nor tested. Do not create or upgrade an instance to those +values. -The API source and canonical generated custom resource definition (CRD) include -9.1, but the inspected Helm Chart CRD copy is stale and omits it. Verify the -installed CRD during release acceptance; a supported package must admit all -three supported lines. +Confirm during release acceptance that the installed schema admits all three +supported lines: + +```bash +kubectl explain valkey.spec.version +``` Inventory all instance versions with: @@ -68,7 +107,6 @@ out or that every process runs the desired line. Before a production rollout or upgrade, obtain the release-specific information that is not defined in this repository: -- the final release date and supported platform versions; - the supported source-to-target product upgrade paths; - component image digests and security advisories; - release-specific backup, rollback, and support procedures; diff --git a/docs/en/limitations.mdx b/docs/en/limitations.mdx index a5166a2..bd50259 100644 --- a/docs/en/limitations.mdx +++ b/docs/en/limitations.mdx @@ -8,7 +8,7 @@ title: Current Limitations # Current Limitations -The following boundaries apply to the 2.0.0 documentation baseline. +The following boundaries apply to Alauda Cache Service E2 version 2.0.0. ## Management interface @@ -18,15 +18,15 @@ automation. ## Server versions Only Valkey 7.2, 8.1, and 9.1 are supported. An installed custom resource -definition (CRD) may still accept `8.0` or `9.0` for compatibility with upstream -API history. That does not establish product support: the 2.0.0 Operator image -map selects only 7.2, 8.1, and 9.1, and the pinned image source builds only -those three lines. - -The inspected Helm Chart CRD copy is stale and omits `9.0` and `9.1`, while the -API source and canonical generated CRD include both. Verify that the delivered -2.0.0 package installs a schema that admits 9.1. A missing 9.1 enum is a package -defect, not a reason to bypass admission. +definition (CRD) still accepts `8.0` and `9.0` because those values remain in +the API schema enum. That does not establish product support: no image is +shipped for either line, so without an entry in the Operator version map they +resolve to a bare `:8.0` or `:9.0` tag and are usable only with a self-supplied +image. The pinned image source builds only 7.2, 8.1, and 9.1. + +Verify during release acceptance that the delivered 2.0.0 package installs a +schema that admits 9.1. A missing 9.1 enum is a package defect, not a reason to +bypass admission. ## Backup, restore, and disaster recovery diff --git a/docs/en/release_notes.mdx b/docs/en/release_notes.mdx index 3797c6c..b56d788 100644 --- a/docs/en/release_notes.mdx +++ b/docs/en/release_notes.mdx @@ -8,10 +8,22 @@ title: Release Notes # Release Notes -## 2.0.0 — next major release +## Compatibility and support matrix -Version 2.0.0 is the next major release. A release date and platform compatibility -matrix have not been established in this documentation baseline. +The following table shows the compatibility and support matrix between Alauda +Cache Service E2 and Alauda Container Platform versions. + +| Alauda Cache Service E2 Version | Valkey Server Lines | Alauda Container Platform Version | +|:--------------------------------|:--------------------|:----------------------------------| +| v2.0.x | 7.2, 8.1, 9.1 | v4.2, v4.3, v4.4 | + +Alauda Cache Service E2 2.0.x is not supported on Alauda Container Platform +v4.1 or earlier. For support phases and end-of-support dates, see +[Lifecycle Policy](./lifecycle_policy.mdx). + +## 2.0.0 + +Released on 2026-09-08. Version 2.0.0 is the first release of the 2.0.x line. ### Supported Valkey versions @@ -104,10 +116,9 @@ large-key inspection reports, or parameter templates. See ### Known compatibility boundaries - The custom resource definition (CRD) retains `8.0` and `9.0` enum values, but - the Operator image map does not select those unsupported server lines. -- The API source and canonical generated CRD include 9.1, but the inspected Helm - Chart CRD copy is stale and omits it. Release packaging must install the - canonical schema before 9.1 can be admitted. + no image is shipped for either line and the Operator version map does not + select them. They are usable only with a self-supplied image and are neither + supported nor tested. - Cluster `AntiAffinity` has the same shard-local selector scope as `AntiAffinityInShard`, and Cluster `CustomAffinity` is affected by an internal constant mismatch. The Cluster reconcile path also preserves existing @@ -134,7 +145,7 @@ large-key inspection reports, or parameter templates. See ### Before adopting 2.0.0 -The release date and Alauda Container Platform compatibility matrix are still -pending. Validate the product installation, server upgrade path, module +Confirm that the target cluster runs a supported Alauda Container Platform +version. Validate the product installation, server upgrade path, module compatibility, external data-protection procedure, and client behavior in a representative non-production cluster before rollout. diff --git a/docs/en/upgrade.mdx b/docs/en/upgrade.mdx index d1b953e..91080e2 100644 --- a/docs/en/upgrade.mdx +++ b/docs/en/upgrade.mdx @@ -12,15 +12,29 @@ This procedure covers the Alauda Cache Service E2 package and Valkey Operator. I does not upgrade the Valkey server line of an existing instance. For that change, follow [Upgrade Valkey](./how_to/30-upgrade.mdx). +Version 2.0.0 has no predecessor product version, so this procedure applies from +the next 2.0.x release onward. To set up a new environment, follow +[Install](./installation.mdx) instead. + The exact package upload and upgrade command depends on the Alauda Container Platform distribution. It is not defined by the `valkey-operator` repository. Use the approved CLI workflow from the delivered 2.0.0 release package; there is no Web Console procedure for this product. +## Platform compatibility + +Alauda Cache Service E2 2.0.x runs on Alauda Container Platform v4.2, v4.3, and +v4.4 only. It is not supported on v4.1 or earlier: upgrade the platform to v4.2 +or later before installing or upgrading Alauda Cache Service E2. The +[compatibility and support matrix](./release_notes.mdx#compatibility-and-support-matrix) +lists the supported pairings, and [Lifecycle Policy](./lifecycle_policy.mdx) the +support phases for each product version. + ## Before you begin -1. Confirm that the source and target product versions form a supported upgrade - path in the release-specific compatibility matrix. +1. Confirm that the target cluster runs a supported Alauda Container Platform + version, and that the source and target product versions form a supported + upgrade path in the release-specific compatibility matrix. 2. Confirm that every managed instance is `Ready` and that no scaling, restart, certificate, configuration, or server-version operation is running. 3. Complete and test the external data-protection procedure for persistent data. diff --git a/llms.txt b/llms.txt index 4480460..9445c2f 100644 --- a/llms.txt +++ b/llms.txt @@ -11,12 +11,12 @@ Valkey instances through Kubernetes APIs and CLI tools. - [docs/en/architecture.mdx](docs/en/architecture.mdx): Explains how one `Valkey` resource in `rds.valkey.buf.red/v1alpha1` is translated by the Operator into lower-level `Cluster`, `Failover`, and `Sentinel` resources and their StatefulSets and Services, with a table mapping each `spec.arch` value to the workloads it produces. Describes the four reconciliation layers from product API down to the data plane, then details the Cluster architecture (16,384 hash slots, 3-128 shards, 1-5 members per shard), the Failover architecture with its Sentinel deployment and role-selecting Services, and the Replica architecture without Sentinel. Includes an architecture selection matrix, guidance on storage and failure domains, and the meaning of each reported status phase. - [docs/en/index.mdx](docs/en/index.mdx): Top-level navigation entry point for the English documentation set, rendering an auto-generated overview of child pages via the `` component. -- [docs/en/installation.mdx](docs/en/installation.mdx): Installation guide for the Alauda Cache Service E2 version 2.0.0 product package using the CLI workflow supplied for the target Alauda Container Platform environment. Lists prerequisites including cluster permissions for custom resource definitions and admission webhooks, image access, a StorageClass, cert-manager, and a Prometheus-compatible scraper. Provides preflight commands for connectivity, permissions, and storage, then verification steps confirming that the five custom resource definitions are established, that the installed schema admits the supported 9.1 version enum, that the Operator Deployment is available, and that webhooks and their certificates exist. Notes that a stale packaged schema omitting 9.1 is a packaging defect. -- [docs/en/intro.mdx](docs/en/intro.mdx): Introduces Alauda Cache Service E2, which deploys and operates Valkey instances on Kubernetes through declarative custom resources reconciled by the Valkey Operator. States that the product is CLI-only with no Web Console, lists the supported Valkey server lines 7.2, 8.1, and 9.1 with their `spec.version` values, and warns that 8.0 and 9.0 remain in the schema enum without being supported. Compares the Cluster, Failover, and Replica architectures with their minimum production shapes, explains that `replicasOfShard` is a legacy name for total member count, and enumerates implemented capabilities including scaling, rolling upgrades, ACL users, Service types, TLS, persistent storage, exporter metrics, and hardened credential handling. Closes with the responsibility boundary: no backup, restore, or disaster recovery, and asynchronous replication caveats. -- [docs/en/lifecycle_policy.mdx](docs/en/lifecycle_policy.mdx): Separates published product facts from lifecycle information not yet established for Alauda Cache Service E2. Tabulates the 2.0.0 baseline, noting that release date, end of full support, end of maintenance, and the platform compatibility matrix are unpublished. Distinguishes four version dimensions - product version, API version, server line, and container image - with the command or inspection that reveals each. States the supported-version rule for 7.2, 8.1, and 9.1 with inspected patch baselines 7.2.14, 8.1.9, and 9.1.1, warns that `status.lastVersion` is controller bookkeeping rather than runtime proof, and lists the release-specific inputs required before a production rollout. -- [docs/en/limitations.mdx](docs/en/limitations.mdx): Catalogues the boundaries of the 2.0.0 baseline: no Web Console, support restricted to Valkey 7.2, 8.1, and 9.1 despite a broader schema enum, and no backup, restore, or disaster recovery. Documents verified implementation defects including the unusable fixed NodePort format, `spec.storage.retainAfterDeleted` having no effect so persistent volume claims always remain after deletion, `spec.storage.accessMode` being ignored in favour of `ReadWriteOnce`, Cluster anti-affinity policies applying only within a shard, and Cluster affinity changes reaching only later-created StatefulSets. Also covers the TLS certificate and client-certificate boundary, unavailable modules, configuration filtering behaviour, and the monitoring integration the shipped ServiceMonitor does not provide. -- [docs/en/release_notes.mdx](docs/en/release_notes.mdx): Release notes for version 2.0.0, listing the supported Valkey lines with their inspected image-source patch baselines, the verified feature scope, and the API and architecture contract including the `rds.valkey.buf.red/v1alpha1` `Valkey` kind and its shard and member ranges. Records operational changes to resource validation, downgrade rejection, exporter defaults, pause and restart annotations, and cert-manager requirements, then details the credential-protection hardening: hashed ACL passwords, encrypted configuration credentials, redacted `CONFIG GET` output, exporter Secret resolution, memory-backed Sentinel configuration, and Pod Security Admission restricted contexts. Closes with excluded capabilities and the known compatibility boundaries carried into this release. -- [docs/en/upgrade.mdx](docs/en/upgrade.mdx): Procedure for upgrading the Alauda Cache Service E2 package and Valkey Operator, distinct from upgrading the Valkey server line of an existing instance. Covers prerequisites such as confirming a supported upgrade path, verifying that every instance is Ready with no operation in progress, completing external data protection, and recording specifications without exporting Secret values. Provides commands to record current state, apply the release's approved CLI package workflow, and watch the Operator roll out. Verification confirms established custom resource definitions, expected images, instances returning to Ready, and working application traffic. Warns against rolling back the Operator image or schemas independently. +- [docs/en/installation.mdx](docs/en/installation.mdx): Installation guide for the Alauda Cache Service E2 version 2.0.0 product package using the CLI workflow supplied for the target Alauda Container Platform environment. Lists prerequisites including Alauda Container Platform v4.2, v4.3, or v4.4, cluster permissions for custom resource definitions and admission webhooks, image access, a StorageClass, cert-manager, and a Prometheus-compatible scraper, and notes that the registry, namespace, channel, and approval strategy come from the delivered release package. Provides preflight commands for connectivity, permissions, and storage, then verification steps confirming that the five custom resource definitions are established, that the installed schema admits the supported 7.2, 8.1, and 9.1 version enum, that the Operator Deployment is available, and that webhooks and their certificates exist. +- [docs/en/intro.mdx](docs/en/intro.mdx): Introduces Alauda Cache Service E2, which deploys and operates Valkey instances on Kubernetes through declarative custom resources reconciled by the Valkey Operator. States that the product is CLI-only with no Web Console, gives the current release 2.0.0 with its 2026-09-08 release date and support on Alauda Container Platform v4.2, v4.3, and v4.4, lists the supported Valkey server lines 7.2, 8.1, and 9.1 with their `spec.version` values, and warns that 8.0 and 9.0 remain in the schema enum with no shipped image. Compares the Cluster, Failover, and Replica architectures, explains that `replicasOfShard` is a legacy name for total member count, and enumerates implemented capabilities. Closes with the responsibility boundary: no backup, restore, or disaster recovery, and asynchronous replication caveats. +- [docs/en/lifecycle_policy.mdx](docs/en/lifecycle_policy.mdx): Publishes the support lifecycle for released versions of Alauda Cache Service E2: version 2.0.x was released on 2026-09-08, reaches end of full support on 2027-09-30 and end of maintenance on 2028-09-30, and runs on Alauda Container Platform v4.2, v4.3, and v4.4. States the release policy for patch, minor, and major versions, defines the two support phases - Full Support in year one for all fixes, Maintenance in year two for critical fixes only - and lists the upstream patching, security update, and upgrade assistance commitments. Distinguishes four version dimensions - product version, API version, server line, and container image - with the command that reveals each, states the supported-version rule for 7.2, 8.1, and 9.1 with patch baselines 7.2.14, 8.1.9, and 9.1.1, and lists the release-specific inputs still required before a production rollout. +- [docs/en/limitations.mdx](docs/en/limitations.mdx): Catalogues the boundaries of Alauda Cache Service E2 version 2.0.0: no Web Console, support restricted to Valkey 7.2, 8.1, and 9.1 despite a broader schema enum for which no image ships, and no backup, restore, or disaster recovery. Documents verified implementation defects including the unusable fixed NodePort format, `spec.storage.retainAfterDeleted` having no effect so persistent volume claims always remain after deletion, `spec.storage.accessMode` being ignored in favour of `ReadWriteOnce`, Cluster anti-affinity policies applying only within a shard, and Cluster affinity changes reaching only later-created StatefulSets. Also covers the TLS certificate and client-certificate boundary, unavailable modules, configuration filtering behaviour, and the monitoring integration the shipped ServiceMonitor does not provide. +- [docs/en/release_notes.mdx](docs/en/release_notes.mdx): Release notes for version 2.0.0, opening with the compatibility and support matrix that pairs Alauda Cache Service E2 v2.0.x with Valkey server lines 7.2, 8.1, and 9.1 and with Alauda Container Platform v4.2, v4.3, and v4.4. Records the 2026-09-08 release date, the inspected image-source patch baselines, the verified feature scope, and the API and architecture contract including the `rds.valkey.buf.red/v1alpha1` `Valkey` kind and its shard and member ranges. Records operational changes to resource validation, downgrade rejection, exporter defaults, pause and restart annotations, and cert-manager requirements, then details the credential-protection hardening: hashed ACL passwords, encrypted configuration credentials, redacted `CONFIG GET` output, exporter Secret resolution, memory-backed Sentinel configuration, and Pod Security Admission restricted contexts. Closes with excluded capabilities and the known compatibility boundaries. +- [docs/en/upgrade.mdx](docs/en/upgrade.mdx): Procedure for upgrading the Alauda Cache Service E2 package and Valkey Operator, distinct from upgrading the Valkey server line of an existing instance, and noting that version 2.0.0 has no predecessor product version so the procedure applies from the next 2.0.x release onward. States that v2.0.x runs on Alauda Container Platform v4.2, v4.3, and v4.4 only and is unsupported on v4.1 or earlier. Covers prerequisites such as confirming a supported upgrade path, verifying that every instance is Ready with no operation in progress, completing external data protection, and recording specifications without exporting Secret values. Provides commands to record current state, apply the release's approved CLI package workflow, and watch the Operator roll out. Verification confirms established custom resource definitions, expected images, instances returning to Ready, and working application traffic. ## apis diff --git a/llmstxt-state.json b/llmstxt-state.json index bd323f0..b1054d0 100644 --- a/llmstxt-state.json +++ b/llmstxt-state.json @@ -3,7 +3,7 @@ "generator_version": 3, "project_name": "Alauda Cache Service E2 Documentation", "summary": "CLI-focused documentation for deploying and operating Valkey on Kubernetes.", - "generated_at": "2026-08-12T07:09:47Z", + "generated_at": "2026-09-08T06:15:12Z", "include_patterns": [ "**/*.md", "**/*.mdx" @@ -18,7 +18,7 @@ "**/llmstxt-state.json", "README.md", "**/.DS_Store", - "docs/agent/**", + "agent/**", "AGENTS.md", "CLAUDE.md" ], @@ -54,11 +54,11 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/apis/kubernetes_apis/valkey/valkey.mdx": { - "sha256": "701bb8989ce817f960dd7ee52e08052370427a40e5dfce995e55625d77a3d3b7", - "size": 3372, + "sha256": "95e39ad7f398b9e9f39faedb0f35d4f911aac11c0fd3719dcc4f8898de668985", + "size": 3352, "description": "API reference for `Valkey`, the high-level namespaced resource used to create and operate an instance, rendering the schema for `valkeys.rds.valkey.buf.red` via the `` component. Tabulates the main specification fields - version, architecture, replicas and initial slot plan, resources, custom configurations, modules, storage, access and TLS, Pod annotations, affinity policy, node selector, tolerations, security context, exporter, and Sentinel settings - each with its 2.0.0 boundary, including fields the schema accepts but the implementation ignores. Also documents the status fields, noting that `lastVersion` and `lastShardCount` are reconciliation bookkeeping rather than observed runtime state.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/architecture.mdx": { "sha256": "17aee012ebc58333c5113726e0015250003880b04ac253ff35ff32d45f4c51ef", @@ -68,11 +68,11 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/functions/10-create-instance.mdx": { - "sha256": "b9d26027a865df8e56088a0eaed4cc9b80069a9bb419c95443e7412bee324d5a", - "size": 5882, + "sha256": "d1539464723516ac21b50f087e133c84df03dce14bc9b37c478be30724991c09", + "size": 5864, "description": "Guide to creating an instance with the high-level `Valkey` custom resource. Lists the decisions to make before creating - architecture, resource requests and limits, persistent storage, and redundancy - then tabulates each main specification field with its required decision, including the note that generated persistent volume claims always request `ReadWriteOnce` and that a StorageClass without a capacity derives twice the memory limit. Provides complete manifests for Cluster, Failover, and Replica instances, followed by verification: watching the phase reach Ready, inspecting child resources and Pods, reading the printed columns, and confirming topology with `CLUSTER INFO` or `INFO replication`.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/functions/15-delete-instance.mdx": { "sha256": "337b4f76855aea8cdb56021e365a9cb88c91b36d8bfd7986fa1d3c188c973fc6", @@ -89,18 +89,18 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/functions/30-parameter.mdx": { - "sha256": "c64b7051935d6eda2f0863ec8e4dd04705af7a20fb42d4e741c14f72a57c1037", - "size": 6089, + "sha256": "a3740cfc437e29ccc4ea889210ce26b7ef128edfaba2a5a9f542fc587bc04921", + "size": 6217, "description": "Guide to setting Valkey server directives through `spec.customConfigs`, explaining that the Operator renders the configuration, compares it with the last applied version, and either issues `CONFIG SET` to ready nodes or triggers a rolling restart. Lists the checks to perform before changing parameters, shows hot updates and key removal by merge patch, enumerates the restart-required directives, and gives the full Operator-owned forbidden list including credential and TLS passphrase directives, noting that filtering is case-insensitive on every configuration path. Covers Sentinel monitor settings and their unvalidated passthrough, and verification with `CONFIG GET`, including that credential values are redacted on the delivered images.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/functions/40-accessmethod.mdx": { - "sha256": "b6ae72b33bdb3a8a4421c4521ffb48f34551bcef2543000b64dc59e0ccfc8bee", - "size": 5398, + "sha256": "deff743d68621d7c017ad205188937325d7f1c0d0bf36c94d401756e1bbf31a9", + "size": 5336, "description": "Guide to configuring instance access under `spec.access`. Compares the ClusterIP, NodePort, and LoadBalancer Service types and explains that the Cluster bootstrap Service stays ClusterIP while the requested type applies to generated per-Pod Services. Advises leaving fixed ports unset because the schema and runtime parser formats conflict, shows how to switch access type, gives the in-cluster Service names for each architecture, and covers the single-stack Internet Protocol family preference. Details enabling TLS through cert-manager, the generated `Certificate` and Secret, the requirement for a trusted client certificate, and the certificate subject alternative name boundary that makes redirected Cluster connections unverifiable.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/functions/50-update.mdx": { "sha256": "32e6ed0685ef67ebbe280bd84ba8a23d7f29399515725f0dadeba05a239ab619", @@ -138,18 +138,18 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/functions/90-restart.mdx": { - "sha256": "cddfbdf86063a2295d8e5747b3a122c2e72046e7650ca67e35ce5959664ef51d", - "size": 1683, + "sha256": "1afd131bcf6731c377bee4e585db95a2bb5bf0a4a22068f8b0cd4af5038f0128", + "size": 1660, "description": "Guide to triggering a rolling restart by setting a new timestamp in the `kubectl.kubernetes.io/restartedAt` Pod annotation, which updates the workload template and replaces Pods; the value must parse as a timestamp and be later than the previously recorded one, so reusing or decreasing it requests nothing. Lists preconditions covering instance readiness, replica and quorum health, absence of concurrent operations, and verified data protection. Shows the patch and the commands to watch progress, then requires verifying connectivity, authentication, slot coverage or primary selection, replication, and metrics rather than trusting Pod timestamps. States that zero downtime is not guaranteed.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/functions/index.mdx": { - "sha256": "3e56afcf087473200fd5f2f0c38374ee4116be30c121de7c7af894eae239848f", - "size": 83, + "sha256": "dafbe89b18730dc8fb38e89b103154975e38598b95237d16faf85dcac7fb0606", + "size": 91, "description": "Landing page for the feature guides section, rendering an auto-generated overview of the guides via the `` component.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/how_to/20-cluster-scaling.mdx": { "sha256": "8c601e47f73c488461042c410c283789439387b24588bbeabff5e46d303d8318", @@ -194,11 +194,11 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/how_to/index.mdx": { - "sha256": "37f1ead8d088f993d026018697a91eb6061d8589a9a47bda9133829cc1b0a60b", - "size": 82, + "sha256": "0fd54c1fc7884ddb74b6965e646f78255b4c50c59e674f3b7e512e07bffc3f8d", + "size": 90, "description": "Landing page for the how-to section, rendering an auto-generated overview of the operational guides via the `` component.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/index.mdx": { "sha256": "31a0125363af9bfae0600d518245b18b9e12c0500f59696b84f44b0f57756ebb", @@ -208,46 +208,46 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/installation.mdx": { - "sha256": "b130189c398a2783d205927890210e42b174320d50679584e77b7924d0ecc4b7", - "size": 5038, - "description": "Installation guide for the Alauda Cache Service E2 version 2.0.0 product package using the CLI workflow supplied for the target Alauda Container Platform environment. Lists prerequisites including cluster permissions for custom resource definitions and admission webhooks, image access, a StorageClass, cert-manager, and a Prometheus-compatible scraper. Provides preflight commands for connectivity, permissions, and storage, then verification steps confirming that the five custom resource definitions are established, that the installed schema admits the supported 9.1 version enum, that the Operator Deployment is available, and that webhooks and their certificates exist. Notes that a stale packaged schema omitting 9.1 is a packaging defect.", + "sha256": "d3011be8d1912e8dd32b3b06aa5d45f30e3a2636bedd5bcd1645b0a1351fbb23", + "size": 5004, + "description": "Installation guide for the Alauda Cache Service E2 version 2.0.0 product package using the CLI workflow supplied for the target Alauda Container Platform environment. Lists prerequisites including Alauda Container Platform v4.2, v4.3, or v4.4, cluster permissions for custom resource definitions and admission webhooks, image access, a StorageClass, cert-manager, and a Prometheus-compatible scraper, and notes that the registry, namespace, channel, and approval strategy come from the delivered release package. Provides preflight commands for connectivity, permissions, and storage, then verification steps confirming that the five custom resource definitions are established, that the installed schema admits the supported 7.2, 8.1, and 9.1 version enum, that the Operator Deployment is available, and that webhooks and their certificates exist.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/intro.mdx": { - "sha256": "7d6597ed36432d8f2c7aa566ab5e1b80d3490760112efeac907d132c353d6850", - "size": 4141, - "description": "Introduces Alauda Cache Service E2, which deploys and operates Valkey instances on Kubernetes through declarative custom resources reconciled by the Valkey Operator. States that the product is CLI-only with no Web Console, lists the supported Valkey server lines 7.2, 8.1, and 9.1 with their `spec.version` values, and warns that 8.0 and 9.0 remain in the schema enum without being supported. Compares the Cluster, Failover, and Replica architectures with their minimum production shapes, explains that `replicasOfShard` is a legacy name for total member count, and enumerates implemented capabilities including scaling, rolling upgrades, ACL users, Service types, TLS, persistent storage, exporter metrics, and hardened credential handling. Closes with the responsibility boundary: no backup, restore, or disaster recovery, and asynchronous replication caveats.", + "sha256": "20b346cf29f9465d9b4614cd75ad1eb16d5c489c65463a07bc54a5187eed056d", + "size": 5319, + "description": "Introduces Alauda Cache Service E2, which deploys and operates Valkey instances on Kubernetes through declarative custom resources reconciled by the Valkey Operator. States that the product is CLI-only with no Web Console, gives the current release 2.0.0 with its 2026-09-08 release date and support on Alauda Container Platform v4.2, v4.3, and v4.4, lists the supported Valkey server lines 7.2, 8.1, and 9.1 with their `spec.version` values, and warns that 8.0 and 9.0 remain in the schema enum with no shipped image. Compares the Cluster, Failover, and Replica architectures, explains that `replicasOfShard` is a legacy name for total member count, and enumerates implemented capabilities. Closes with the responsibility boundary: no backup, restore, or disaster recovery, and asynchronous replication caveats.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/lifecycle_policy.mdx": { - "sha256": "e64fb9b546ccac7da2ae876bbcebce8661ed9b49f79496b577ef8fb1fbb21d41", - "size": 3381, - "description": "Separates published product facts from lifecycle information not yet established for Alauda Cache Service E2. Tabulates the 2.0.0 baseline, noting that release date, end of full support, end of maintenance, and the platform compatibility matrix are unpublished. Distinguishes four version dimensions - product version, API version, server line, and container image - with the command or inspection that reveals each. States the supported-version rule for 7.2, 8.1, and 9.1 with inspected patch baselines 7.2.14, 8.1.9, and 9.1.1, warns that `status.lastVersion` is controller bookkeeping rather than runtime proof, and lists the release-specific inputs required before a production rollout.", + "sha256": "4f68c02023227a35777a67ec78456e81a41d27901179f8e2af40957ca03565d5", + "size": 5092, + "description": "Publishes the support lifecycle for released versions of Alauda Cache Service E2: version 2.0.x was released on 2026-09-08, reaches end of full support on 2027-09-30 and end of maintenance on 2028-09-30, and runs on Alauda Container Platform v4.2, v4.3, and v4.4. States the release policy for patch, minor, and major versions, defines the two support phases - Full Support in year one for all fixes, Maintenance in year two for critical fixes only - and lists the upstream patching, security update, and upgrade assistance commitments. Distinguishes four version dimensions - product version, API version, server line, and container image - with the command that reveals each, states the supported-version rule for 7.2, 8.1, and 9.1 with patch baselines 7.2.14, 8.1.9, and 9.1.1, and lists the release-specific inputs still required before a production rollout.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/limitations.mdx": { - "sha256": "8c00abd3283c37bd3f556b894d3dab1a1cddf0ee483ce66ab0acd410c59b6060", - "size": 6266, - "description": "Catalogues the boundaries of the 2.0.0 baseline: no Web Console, support restricted to Valkey 7.2, 8.1, and 9.1 despite a broader schema enum, and no backup, restore, or disaster recovery. Documents verified implementation defects including the unusable fixed NodePort format, `spec.storage.retainAfterDeleted` having no effect so persistent volume claims always remain after deletion, `spec.storage.accessMode` being ignored in favour of `ReadWriteOnce`, Cluster anti-affinity policies applying only within a shard, and Cluster affinity changes reaching only later-created StatefulSets. Also covers the TLS certificate and client-certificate boundary, unavailable modules, configuration filtering behaviour, and the monitoring integration the shipped ServiceMonitor does not provide.", + "sha256": "9e6dcd15e1015c561f7d74c0fd9f3ca26c25a94e79dd7c9ea74b929088fd1007", + "size": 6463, + "description": "Catalogues the boundaries of Alauda Cache Service E2 version 2.0.0: no Web Console, support restricted to Valkey 7.2, 8.1, and 9.1 despite a broader schema enum for which no image ships, and no backup, restore, or disaster recovery. Documents verified implementation defects including the unusable fixed NodePort format, `spec.storage.retainAfterDeleted` having no effect so persistent volume claims always remain after deletion, `spec.storage.accessMode` being ignored in favour of `ReadWriteOnce`, Cluster anti-affinity policies applying only within a shard, and Cluster affinity changes reaching only later-created StatefulSets. Also covers the TLS certificate and client-certificate boundary, unavailable modules, configuration filtering behaviour, and the monitoring integration the shipped ServiceMonitor does not provide.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/release_notes.mdx": { - "sha256": "cdcbd7a61e6a656ff1c1440cb8c3b31ea8b27103d23e39cc8a4979799d4c5f66", - "size": 6373, - "description": "Release notes for version 2.0.0, listing the supported Valkey lines with their inspected image-source patch baselines, the verified feature scope, and the API and architecture contract including the `rds.valkey.buf.red/v1alpha1` `Valkey` kind and its shard and member ranges. Records operational changes to resource validation, downgrade rejection, exporter defaults, pause and restart annotations, and cert-manager requirements, then details the credential-protection hardening: hashed ACL passwords, encrypted configuration credentials, redacted `CONFIG GET` output, exporter Secret resolution, memory-backed Sentinel configuration, and Pod Security Admission restricted contexts. Closes with excluded capabilities and the known compatibility boundaries carried into this release.", + "sha256": "1a9f714f5dfad0d2e584c3e90f2739791d0d42ef693e2668fbb929d19a3de00f", + "size": 6978, + "description": "Release notes for version 2.0.0, opening with the compatibility and support matrix that pairs Alauda Cache Service E2 v2.0.x with Valkey server lines 7.2, 8.1, and 9.1 and with Alauda Container Platform v4.2, v4.3, and v4.4. Records the 2026-09-08 release date, the inspected image-source patch baselines, the verified feature scope, and the API and architecture contract including the `rds.valkey.buf.red/v1alpha1` `Valkey` kind and its shard and member ranges. Records operational changes to resource validation, downgrade rejection, exporter defaults, pause and restart annotations, and cert-manager requirements, then details the credential-protection hardening: hashed ACL passwords, encrypted configuration credentials, redacted `CONFIG GET` output, exporter Secret resolution, memory-backed Sentinel configuration, and Pod Security Admission restricted contexts. Closes with excluded capabilities and the known compatibility boundaries.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/trouble_shooting/10-instance-not-ready.mdx": { - "sha256": "d697cb0c1ab5e34688815e897469e58046c57bce6a70d94691e82198c8e9daef", - "size": 5350, + "sha256": "dd8b9423caa749340f2b032926e3d6158d8dbddac64d664b057216292fbddce7", + "size": 5354, "description": "Diagnostic procedure for an instance that remains Initializing, Rebalancing, or Failed, or whose Pods and Services are unavailable. Begins by preserving state rather than restarting or editing child resources, then reproduces admission failures with a server-side dry run and tabulates common validation boundaries and their checks, including that an oversized shard count fails late on the child resource rather than at admission. Works through unschedulable Pods and the anti-affinity node requirements per architecture, pending persistent volume claims, TLS and issuer resources, container and Operator logs, and topology health, closing with the contents of an escalation package.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/trouble_shooting/20-large-key-analysis.mdx": { "sha256": "93715e83298e3933dc59546b97e5b1f59559acf5ddfbcbf9abfc1a05161a6ac1", @@ -257,18 +257,18 @@ "updated_at": "2026-08-12T07:09:47Z" }, "docs/en/trouble_shooting/index.mdx": { - "sha256": "a40b14454992dc26c736f69f5e35b18025f62ed92c9cb35475aa19c6e7b89609", - "size": 93, + "sha256": "2076c9e3cb419e83d472983878e332f1e8aa19e74b4e03e4bf8333e73f7aa678", + "size": 92, "description": "Landing page for the troubleshooting section, rendering an auto-generated overview of the diagnostic guides via the `` component.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" }, "docs/en/upgrade.mdx": { - "sha256": "23f7b5d9df9d90f3f868d1200f9fefc45ea38c683ccd66d5485017bfd628d981", - "size": 4396, - "description": "Procedure for upgrading the Alauda Cache Service E2 package and Valkey Operator, distinct from upgrading the Valkey server line of an existing instance. Covers prerequisites such as confirming a supported upgrade path, verifying that every instance is Ready with no operation in progress, completing external data protection, and recording specifications without exporting Secret values. Provides commands to record current state, apply the release's approved CLI package workflow, and watch the Operator roll out. Verification confirms established custom resource definitions, expected images, instances returning to Ready, and working application traffic. Warns against rolling back the Operator image or schemas independently.", + "sha256": "b93dbb16d3289cffaac4c6fcc1f4ba41fafefa48075c4f23cfe87f5233d7b83e", + "size": 5135, + "description": "Procedure for upgrading the Alauda Cache Service E2 package and Valkey Operator, distinct from upgrading the Valkey server line of an existing instance, and noting that version 2.0.0 has no predecessor product version so the procedure applies from the next 2.0.x release onward. States that v2.0.x runs on Alauda Container Platform v4.2, v4.3, and v4.4 only and is unsupported on v4.1 or earlier. Covers prerequisites such as confirming a supported upgrade path, verifying that every instance is Ready with no operation in progress, completing external data protection, and recording specifications without exporting Secret values. Provides commands to record current state, apply the release's approved CLI package workflow, and watch the Operator roll out. Verification confirms established custom resource definitions, expected images, instances returning to Ready, and working application traffic.", "generation_method": "ai_agent_reading", - "updated_at": "2026-08-12T07:09:47Z" + "updated_at": "2026-09-08T06:15:12Z" } } }