install, upgrade for acp 4.1 and fix dr#104
Conversation
WalkthroughDocumentation reorganizes install/upgrade flows around a Core-first model, adds a new "Upload Packages" guide for the violet CLI, changes global-cluster upgrade sequencing and DR upload behavior, updates hybrid migration/image-sync instructions, and fixes a link anchor and minor formatting. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Admin
participant Portal as Customer Portal
participant CP as Control Plane Node
participant Script as upgrade.sh
participant Registry as Image Registry
participant Cluster as Global Cluster
Admin->>Portal: Download Core (hybrid) package
Admin->>CP: Upload package to control plane
Admin->>CP: Extract package
Admin->>Script: Run upgrade.sh --only-sync-image=true
Script->>Registry: Sync multi-arch images
Script-->>Admin: Sync complete
Admin->>Cluster: kubectl get cluster.platform... (check label)
alt cpaas.io/node-arch-constraint present
Admin->>Cluster: kubectl label/patch to remove constraint
else
Note over Admin,Cluster: No label removal needed
end
sequenceDiagram
autonumber
actor Operator
participant Standby as Standby Cluster
participant Primary as Primary Cluster
participant Registry as Image Registry
participant Violet as violet CLI
participant Web as Web Console
Operator->>Violet: violet push --dest-repo=<standby-VIP> (upload to standby)
Violet->>Registry: push images to standby repo
Operator->>Violet: violet push (upload to primary)
Violet->>Registry: push images to primary repo
Operator->>Standby: Pre-check ProductBase.alternativeURLs (kubectl/apply)
Operator->>Standby: Upgrade standby cluster
Operator->>Primary: Upgrade primary cluster
Operator->>Standby: Port-forward & reinstall etcd-sync (post-upgrade)
Operator->>Operator: Run data-consistency verification (curl/kubectl)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/en/upgrade/upgrade_global_cluster.mdx (1)
11-14: Broken in-page anchors: remove escaped braces on custom IDsThe headings use escaped braces for custom IDs:
\{#standard}and\{#global_dr}. In MDX/remark, escaping likely prevents the ID from being applied, breaking links like[Standard procedure](#standard)and[global DR procedure](#global_dr).Apply this diff to fix anchors and normalize heading capitalization:
-## Standard procedure \{#standard} +## Standard procedure {#standard} @@ -## global DR procedure \{#global_dr} +## Global DR procedure {#global_dr}Also applies to: 67-68
♻️ Duplicate comments (1)
docs/en/extend/upload_package.mdx (1)
333-335: Align role wording (duplicate in Helm table)Same consistency fix as above for the Helm table.
- Required. Username of a local user with the - <code>Platform Administrator role</code>. + Required. Username of a local user whose role property is + <code>System</code> and role name is <code>platform-admin-system</code>.
🧹 Nitpick comments (14)
docs/en/configure/clusters/on-premises.mdx (1)
12-12: Align link text with new anchor and terminologyThe link target now points to the “Download Core Package” anchor, but the visible text still says “Download Installation Package.” Update the link text for consistency.
-1. If you downloaded a single-architecture installation package from [Download Installation Package](/install/prepare/download.mdx#download_core_package), ensure your node machines have the same architecture as the package. Otherwise, nodes won't start due to missing architecture-specific images. +1. If you downloaded a single-architecture installation package from [Download Core Package](/install/prepare/download.mdx#download_core_package), ensure your node machines have the same architecture as the package. Otherwise, nodes won't start due to missing architecture-specific images.docs/en/install/overview.mdx (2)
7-13: Link Extensions to the new upload guideYou reference installing Extensions; link to the new guide to streamline navigation.
-After the installation, you can **create new workload clusters** or **connect existing ones**, and install additional **Extensions** to enhance the platform’s capabilities. +After the installation, you can **create new workload clusters** or **connect existing ones**, and install additional **[Extensions](../extend/upload_package.mdx)** to enhance the platform’s capabilities.
23-32: Use “Download Core Package” and align VIP wording
- Make the prep bullet link directly to the new “Download Core Package” section.
- Prefer “Self-built VIP” to match terminology used elsewhere in the docs.
-1. **Preparation Stage** - - **Prerequisite Check**: Ensure that all node hardware, network, and OS meet the requirements, such as kernel version, CPU architecture, and network configuration. - - **Installation Package Download**: Log in to the Customer Portal to obtain the latest installation package. +1. **Preparation Stage** + - **Prerequisite Check**: Ensure that all node hardware, network, and OS meet the requirements, such as kernel version, CPU architecture, and network configuration. + - **[Download Core Package](/install/prepare/download.mdx#download_core_package)**: Log in to the Customer Portal to obtain the latest Core package. - **Node Preprocessing**: Complete the preprocessing work of all nodes. 2. **Execution Stage** - - **Installation Package Upload and Extraction**: Upload the installation package to the target control plane node (recommended directory: `/root/cpaas-install`) and extract the installation resources. - - **Start the Installer**: Execute the installation script (such as `bash setup.sh`) on the control plane node, and select the network plugin (Kube-OVN or Calico), IP protocol mode (IPv4/IPv6/dual stack), and VIP configuration according to the actual environment. + - **Installation Package Upload and Extraction**: Upload the installation package to the target control plane node (recommended directory: `/root/cpaas-install`) and extract the installation resources. + - **Start the Installer**: Execute the installation script (such as `bash setup.sh`) on the control plane node, and select the network plugin (Kube-OVN or Calico), IP protocol mode (IPv4/IPv6/dual stack), and, if needed, the **Self-built VIP** configuration according to the actual environment.docs/en/extend/upload_package.mdx (4)
17-19: Clarify OS support and architectures; improve grammarSpecify Windows architecture explicitly and simplify the phrasing to address the grammar warning.
-- Linux, macOS, and Windows -- Linux and macOS support both x86 and ARM architectures +- Supported operating systems: Linux, macOS, Windows +- Supported CPU architectures: + - Linux: x86_64 (amd64), ARM64 + - macOS: x86_64 (amd64), ARM64 + - Windows: x86_64 (amd64)
70-73: Use proper code fence for PowerShellThe Windows example uses PowerShell. Use the powershell code fence for correct highlighting.
- ```bash + ```powershell # Windows x86 mv -Force violet_windows_amd64.exe violet.exe ```
103-106: Warn against passing passwords via CLI flagsProcess arguments can be visible to other users. Add a security note recommending safer alternatives where possible.
violet push opensearch-operator.v3.14.2.tgz --platform-address https://192.168.0.1 --platform-username <user> --platform-password <password>+
+Avoid passing credentials via command-line flags on multi-user systems because process arguments may be visible to other users. If the tool supports it, prefer environment variables, interactive prompts, or a password file. If flags must be used, clear your shell history afterwards.
+--- `165-171`: **Align role wording with the “Permission Requirements” section** Keep the parameter description consistent with the stated requirement (System/platform-admin-system). ```diff - Required. Username of a local user with the - <code>Platform Administrator role</code>. + Required. Username of a local user whose role property is + <code>System</code> and role name is <code>platform-admin-system</code>.docs/en/install/prepare/download.mdx (2)
35-39: Prefer deterministic label removal over kubectl editEditing interactively is error-prone. Provide a direct label removal command.
kubectl get cluster.platform.tkestack.io global -oyaml | grep cpaas.io/node-arch-constraint -# If there is output, edit the resource to remove the label; otherwise, you can skip this step. -kubectl edit cluster.platform.tkestack.io global ### Edit the labels field and delete cpaas.io/node-arch-constraint +# If there is output, remove the label directly; otherwise, you can skip this step. +kubectl label cluster.platform.tkestack.io global cpaas.io/node-arch-constraint- ### The trailing '-' deletes the label
21-40: Add a quick verification step for hybrid readinessOptional but helpful to confirm both architectures are recognized after syncing images.
3. After the script completes, check the `cluster.platform.tkestack.io` resource to verify whether the label `cpaas.io/node-arch-constraint` exists. If it does, you must remove it: ```shell kubectl get cluster.platform.tkestack.io global -oyaml | grep cpaas.io/node-arch-constraint # If there is output, edit the resource to remove the label; otherwise, you can skip this step. kubectl edit cluster.platform.tkestack.io global ### Edit the labels field and delete cpaas.io/node-arch-constraint ``` + +### Verification + +After synchronization and label removal, verify node architectures: + +```shell +kubectl get nodes -o=custom-columns=NAME:.metadata.name,ARCH:.status.nodeInfo.architecture +```docs/en/upgrade/upgrade_global_cluster.mdx (5)
34-37: Tighten wording on duration and DR noteMinor clarity tweaks improve operator expectations and readability.
Apply this diff to rephrase:
-Uploading images typically takes about 2 hours, depending on your network and disk performance. - -If your platform uses the global DR, remember that the **standby global cluster also requires image upload**, and plan your maintenance window accordingly. +Uploading images can take up to ~2 hours, depending on network and disk performance. + +If your platform uses global DR, remember the **standby global cluster also requires an image upload**. Plan the maintenance window accordingly.
88-95: UI path labels are inconsistent; confirm intended version differencesThis section uses “Catalog > Cluster Plugin” (Line 91), while later it uses “Marketplace > Cluster Plugins” (Line 138). If this is intentional for 3.18 vs 4.x UI differences, consider adding a short note. Otherwise, standardize the wording.
Also applies to: 136-141
105-123: Add a safe, direct patch command for ProductBase.alternativeURLsGood callout. Provide an operator-friendly kubectl patch example to avoid editing YAML by hand.
+ +Alternatively, patch it directly: + +```bash +kubectl patch productbase base --type merge -p '{"spec":{"alternativeURLs":["https://"]}}' +``` ```If not, update the configuration as follows: @@ - https://<standby-cluster-vip>
145-152: Harden pod selection and reuse the pod nameAvoids subshell parsing issues and handles spaces safely. Also reduces duplication.
-kubectl get po -n cpaas-system -l app=etcd-sync # Ensure pod is 1/1 Running - -kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | awk '{print $1}' | head -1) | grep -i "Start Sync update" -# Wait until the logs contain "Start Sync update" - -# Recreate the pod to trigger synchronization of resources with ownerReferences -kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | awk '{print $1}' | head -1) +kubectl get po -n cpaas-system -l app=etcd-sync # Ensure pod is 1/1 Running + +pod="$(kubectl get po -n cpaas-system -l app=etcd-sync -o jsonpath='{.items[0].metadata.name}')" +kubectl logs -n cpaas-system "$pod" | grep -i "Start Sync update" +# Wait until the logs contain "Start Sync update" + +# Recreate the pod to trigger synchronization of resources with ownerReferences +kubectl delete po -n cpaas-system "$pod"
159-160: Specify scheme in curl URLBe explicit to avoid scheme inference edge cases.
-curl "$(kubectl get svc -n cpaas-system etcd-sync-monitor -ojsonpath='{.spec.clusterIP}')/check" +curl "http://$(kubectl get svc -n cpaas-system etcd-sync-monitor -ojsonpath='{.spec.clusterIP}')/check"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (6)
docs/en/configure/clusters/on-premises.mdx(1 hunks)docs/en/extend/upload_package.mdx(1 hunks)docs/en/install/installing.mdx(1 hunks)docs/en/install/overview.mdx(2 hunks)docs/en/install/prepare/download.mdx(1 hunks)docs/en/upgrade/upgrade_global_cluster.mdx(4 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/en/extend/upload_package.mdx
[grammar] ~17-~17: There might be a mistake here.
Context: ...ing Systems - Linux, macOS, and Windows - Linux and macOS support both x86 and ARM...
(QB_NEW_EN)
🔇 Additional comments (7)
docs/en/install/installing.mdx (1)
85-85: LGTM: whitespace cleanup onlyTrailing-space removal is fine. No content changes.
docs/en/extend/upload_package.mdx (1)
224-230: Verify parameter name/semantics: target-chartrepo vs catalogsourceThe parameter is named --target-chartrepo but the description mentions “catalogsource.” Confirm the correct terminology and applicability for Operators.
Run:
- violet push --help
- violet push operator --help
- violet push helm --help
to verify whether --target-chartrepo applies to Operators or only to Helm charts and update the description accordingly.docs/en/install/prepare/download.mdx (1)
7-13: Good anchor and Core-first guidanceThe new anchor and v4.1 sequencing note look consistent with cross-file links.
docs/en/upgrade/upgrade_global_cluster.mdx (4)
7-7: Clarifies upgrade order — LGTMCalling out that the global cluster must be upgraded before any workload clusters is correct and helpful.
71-82: Data consistency checks — LGTMRenamed section and consolidated command improve flow. Command looks correct for a cluster-scoped
Machineresource.
124-129: Cross-links rely on fixed anchorsThese references to the Standard procedure depend on the custom IDs working. Once the escaped-brace issue is fixed, these links should resolve.
60-63: Grammar Fix & Link Verification Completed
The target documentupgrade_gitops_plugin.mdxand its#procedureanchor were found indocs/en/gitops/upgrade/upgrade_gitops_plugin.mdx. Apply the following update:• File:
docs/en/upgrade/upgrade_global_cluster.mdx(Lines 60–63)-If the `Alauda Container Platform GitOps` is installed in the global cluster, and after the upgrading, the pods of the plugin is running abnormally.Please refer to [Upgrading Alauda Container Platform GitOps](/gitops/upgrade/upgrade_gitops_plugin.html#procedure). +If Alauda Container Platform GitOps is installed in the global cluster and the plugin pods run abnormally after upgrading, refer to [Upgrading Alauda Container Platform GitOps](/gitops/upgrade/upgrade_gitops_plugin.html#procedure).
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/en/install/global_dr.mdx (1)
130-134: Typo: “recreat” → “recreate”Minor but user-facing.
-Once “Start Sync update” appears, recreat one of the pods to re-trigger sync of resources with ownerReference dependencies: +Once “Start Sync update” appears, recreate one of the pods to re-trigger sync of resources with ownerReference dependencies:
🧹 Nitpick comments (22)
docs/en/ui/web_console/customize-left-navigation.mdx (1)
238-243: Disambiguate duplicate “Certificates” headingsThere are two “Certificates”: one under Networking and this top-level section that controls platform certificates. To avoid confusion in customization files and internal comms, rename this comment header to “Platform Certificates”.
-# Certificates +# Platform Certificates - name: platform_certificate_manage icon: certificate href: certificate gate: legacy-certificate-managedocs/en/install/global_dr.mdx (1)
226-230: Clarify --dest-repo usage; add example (built-in vs external registry)Good call-out. Two refinements:
- Make it explicit this applies when using the built-in registry. If an external registry is configured for the standby,
--dest-reposhould point to that endpoint, not necessarily the VIP.- Provide a concrete example to reduce mistakes.
-## Uploading Packages \{#upload_dr_packages} - -When using **`violet`** to upload packages to a standby cluster, you must specify the `--dest-repo` parameter with the VIP of the standby cluster. -If this parameter is omitted, the package will be uploaded to the image repository of the primary cluster, preventing the standby cluster from installing or upgrading the corresponding extension. +## Uploading Packages \{#upload_dr_packages} + +When using **`violet`** to upload packages to a standby global cluster, you must specify the `--dest-repo` parameter so images are pushed to the standby’s image registry. + +- If you use the platform’s built-in registry on the standby cluster, set `--dest-repo` to the standby cluster’s VIP (registry endpoint). +- If you use an external registry on the standby cluster, set `--dest-repo` to that external registry endpoint. + +If `--dest-repo` is omitted, images may be pushed to the primary cluster’s registry, and the standby cluster will be unable to install or upgrade the corresponding extension. + +Example: +```bash +violet push <package.tgz> \ + --platform-address https://<standby-vip> \ + --platform-username <user> \ + --platform-password <password> \ + --dest-repo https://<standby-vip> +```docs/en/upgrade/upgrade_workload_cluster.mdx (1)
16-20: Use extensionless links for route stabilityLinking to MDX filenames can break when the site generator rewrites routes. Prefer extensionless paths.
-For bulk upload instructions, see [Upload All Packages in a Directory](../extend/upload_package.mdx#upload_all_packages). +For bulk upload instructions, see [Upload All Packages in a Directory](../extend/upload_package#upload_all_packages). -For details, see [Upload Packages in a Global DR Environment](../install/global_dr.mdx#upload_dr_packages). +For details, see [Upload Packages in a Global DR Environment](../install/global_dr#upload_dr_packages).docs/en/extend/upload_package.mdx (5)
8-9: Tighten wording to address grammar/styleSmall style tweak improves readability.
-The platform provides a command-line tool **`violet`**, which is used to upload packages downloaded from the Marketplace in the Custom Portal to the platform. +The platform provides a command-line tool, **`violet`**, for uploading packages downloaded from the Marketplace in the Custom Portal to the platform.
105-112: Version formatting in example looks off (“v3.00”)Unless intentional, use a conventional SemVer-like tag to avoid confusing readers.
-RelateImages: [harbor.demo.io/acp/topolvm-operator:v3.11.0 harbor.demo.io/acp/topolvm:v3.11.0 harbor.demo.io/3rdparty/k8scsi/csi-provisioner:v3.00 ...] +RelateImages: [harbor.demo.io/acp/topolvm-operator:v3.11.0 harbor.demo.io/acp/topolvm:v3.11.0 harbor.demo.io/3rdparty/k8scsi/csi-provisioner:v3.0.0 ...]
139-151: Add a DR note about --dest-repo for standby clustersThis page is the canonical violet reference. Add a short note linking to the DR section so users don’t miss the
--dest-reporequirement for standby clusters.The tool automatically detects the package types in the directory. + +> Note (Global DR): +> When pushing to a standby global cluster, you must set `--dest-repo` to the standby’s registry endpoint so images are available on the standby. +> See [Upload Packages in a Global DR Environment](/install/global_dr#upload_dr_packages).
155-161: Use a chart-specific example filenameRe-using the cluster plugin filename for a Helm example can confuse. Use a generic chart name.
-```bash -violet push plugins-cloudedge-v0.3.16-hybrid.tgz \ +```bash +violet push mychart-1.2.3.tgz \ --platform-address https://192.168.0.1 \ --platform-username <user> \ --platform-password <password>--- `163-164`: **Confirm chart repo limitation vs tool capability** This states charts can only be uploaded to the default `public-charts` repo. If violet supports `--target-chartrepo`, consider documenting it here; otherwise the statement is correct. If `--target-chartrepo` is supported, I can draft a short “Common parameters” subsection covering `--platform-address`, `--platform-username`, `--platform-password`, `--dest-repo`, `--target-chartrepo`, `--clusters`, `--skip-push`, `--force`, and `--debug`. </blockquote></details> <details> <summary>docs/en/upgrade/overview.mdx (2)</summary><blockquote> `26-31`: **Tighten Operator/Plugin wording; avoid "Source ="** Minor wording nit to improve clarity and style. Apply: ```diff -* **Operator:** - Only Operators with **Source = <Term name="company" />** are listed and can be upgraded via the cluster upgrade feature. All other Operators are managed through the **OLM** component in the Marketplace and are not included in this process. +* **Operator:** + Only Operators with **Source set to <Term name="company" />** are listed and can be upgraded via the cluster upgrade feature. All other Operators are managed through **OLM** in the Marketplace and are not included in this process.
32-39: DR definitions are concise; small grammar polish on standby definitionCurrent definitions are clear. Consider this tweak for smoother reading.
-* **Standby global cluster:** - Defined as the global cluster that the <Term name="productShort" /> access domain name **does not** resolve to. +* **Standby global cluster:** + Defined as the global cluster that the <Term name="productShort" /> access domain name **does not** resolve to that cluster.docs/en/upgrade/pre-upgrade.mdx (4)
14-21: Prerequisites table is useful; clarify two phrasing nitsTwo small language tweaks for tone/clarity.
-| **Elasticsearch logging** | Must comply with the fix described in *How to Correct the Issue of Node Role Settings in Big Cluster Elasticsearch* (see Custom Portal > Knowledge) | Apply the fix before upgrade | +| **Elasticsearch logging** | Must be configured according to *How to Correct the Issue of Node Role Settings in Big Cluster Elasticsearch* (see Custom Portal > Knowledge) | Apply the fix before the upgrade | @@ -| **Disk space for upgrade package extraction** | At least **250 GB free** if package and extraction path are on the same disk | Free or expand storage | +| **Disk space for upgrade package extraction** | At least **250 GB free** if the package and extraction path are on the same disk | Free or expand storage |
32-36: Tighten wording and link to package upload guidanceMinor grammar fix and a cross-link to the upload instructions helps users complete the flow.
-From the **Custom Portal**, download the **ACP 4.1 Core Package** and the **Extensions package**. -When downloading Extensions, select the scenario: **`For upgrading ACP from 3.18.x to 4.1.x`**. +From the **Custom Portal**, download the **ACP 4.1 Core Package** and the **Extensions** package. +When downloading extensions, select the scenario: **`For upgrading ACP from 3.18.x to 4.1.x`**. +For guidance on uploading packages to the platform, see [Upload Packages](../extend/upload_package.mdx).
39-39: Consider providing a stable reference for the checklist script“Contact technical support to obtain the checklist script” can create delays. If possible, add a stable internal link or filename/version so users can self-serve.
I can add a “Checklist” subsection with a canonical script path and sample usage if you share the script’s location and parameters.
41-44: Add a tracking note for the 4.0→4.1 doc gapSince this is a common path, suggest adding a note or issue link to track publication.
I can open a docs ticket and insert its link here as a placeholder. Want me to proceed?
docs/en/upgrade/upgrade_global_cluster.mdx (8)
11-11: Remove extra space before periodMinor punctuation nit.
-If the global cluster is configured with the **global DR (Disaster Recovery)** solution, follow the [global DR procedure](#global_dr) strictly. Otherwise, follow the [Standard procedure](#standard) . +If the global cluster is configured with the **global DR (Disaster Recovery)** solution, follow the [global DR procedure](#global_dr) strictly. Otherwise, follow the [Standard procedure](#standard).
33-39: Strengthen violet push guidance with a succinct exampleAdding a minimal example helps users recall the shape of the command, especially with --dest-repo for standby.
-If you want to upgrade Operators and Cluster Plugins together with the cluster upgrade, you must upload the Extensions to the platform **before upgrading ACP Core** using **violet**. +If you want to upgrade Operators and Cluster Plugins together with the cluster upgrade, you must upload the Extensions to the platform **before upgrading ACP Core** using **violet**. + +Example: +```bash +# Push extensions to the primary cluster +violet push /path/to/extensions +``` @@ -When using **`violet push`** on a **standby global cluster**, you must specify the `--dest-repo` parameter with the VIP of the standby cluster. +When using **`violet push`** on a **standby global cluster**, specify the `--dest-repo` parameter with the standby cluster VIP. + +Example: +```bash +violet push /path/to/extensions --dest-repo https://<standby-cluster-vip> +```
41-44: Info note is helpful; add variability disclaimerTime can vary widely; consider adding “varies by” wording.
-Uploading images typically takes about 2 hours, depending on your network and disk performance. +Uploading images typically takes about 2 hours, depending on network bandwidth and disk performance; your timing may vary.
71-75: Fix grammar in GitOps note and verify linkSubject-verb agreement and spacing.
-- If the **Alauda Container Platform GitOps** is installed in the global cluster, and after the upgrading, the pods of the plugin is running abnormally.Please refer to [Upgrading Alauda Container Platform GitOps](/gitops/upgrade/upgrade_gitops_plugin.html#procedure). +- If **Alauda Container Platform GitOps** is installed in the global cluster and, after upgrading, the plugin pods are running abnormally, please refer to [Upgrading Alauda Container Platform GitOps](/gitops/upgrade/upgrade_gitops_plugin.html#procedure).Please confirm the absolute path “/gitops/upgrade/upgrade_gitops_plugin.html#procedure” is valid in the published site structure.
91-104: Add optional etcd health check in consistency phaseYou might consider adding an etcd endpoint health check for both clusters to complement Machine state check.
I can propose a succinct, non-invasive check (curling /health endpoint behind port-forward) if desired.
117-123: Parallelize image uploads across clusters to reduce maintenance windowCall out that uploads to primary and standby can be performed in parallel (resources permitting) to shorten the overall window.
-Perform the **Upload images** step on **both** the standby cluster and the primary cluster. +Perform the **Upload images** step on **both** the standby cluster and the primary cluster. You can run these uploads in parallel to reduce the total maintenance window.
125-143: Good pre-check for ProductBase.alternativeURLs; add hint on schemeSome clusters use HTTP in air-gapped environments. Consider noting that the scheme must match the cluster configuration.
- - https://<standby-cluster-vip> + - https://<standby-cluster-vip> # Use the correct scheme (https or http) for your environment
152-172: etcd-sync reinstall steps are solid; minor robustness tweak to pod selectionhead -1 may select a terminating pod. Consider using --field-selector=status.phase=Running to target the running pod when tailing logs and deleting.
-kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | awk '{print $1}' | head -1) | grep -i "Start Sync update" +kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --field-selector=status.phase=Running --no-headers | awk '{print $1}' | head -1) | grep -i "Start Sync update" @@ -kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | awk '{print $1}' | head -1) +kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --field-selector=status.phase=Running --no-headers | awk '{print $1}' | head -1)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (9)
docs/en/extend/upload_package.mdx(1 hunks)docs/en/install/global_dr.mdx(1 hunks)docs/en/install/installing.mdx(2 hunks)docs/en/ui/cli_tools/index.mdx(1 hunks)docs/en/ui/web_console/customize-left-navigation.mdx(2 hunks)docs/en/upgrade/overview.mdx(1 hunks)docs/en/upgrade/pre-upgrade.mdx(1 hunks)docs/en/upgrade/upgrade_global_cluster.mdx(5 hunks)docs/en/upgrade/upgrade_workload_cluster.mdx(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/en/install/installing.mdx
🧰 Additional context used
🪛 LanguageTool
docs/en/upgrade/pre-upgrade.mdx
[style] ~19-~19: Consider using a different verb for a more formal wording.
Context: ...omply with the fix described in *How to Correct the Issue of Node Role Settings in Big ...
(FIX_RESOLVE)
[grammar] ~32-~32: There might be a mistake here.
Context: ...ackage** and the Extensions package. When downloading Extensions, select the ...
(QB_NEW_EN)
docs/en/upgrade/overview.mdx
[grammar] ~26-~26: There might be a mistake here.
Context: ...d Managed Clusters. * Operator: Only Operators with **Source = <Term nam...
(QB_NEW_EN)
[grammar] ~35-~35: There might be a mistake here.
Context: ... cluster. * Primary global cluster: Defined as the global cluster that the <...
(QB_NEW_EN)
[grammar] ~39-~39: There might be a mistake here.
Context: ...ess domain name does not resolve to.
(QB_NEW_EN)
docs/en/extend/upload_package.mdx
[grammar] ~12-~12: There might be a mistake here.
Context: ...llowing types of packages: * Operator * Cluster Plugin * Helm Chart When ...
(QB_NEW_EN)
[grammar] ~13-~13: There might be a mistake here.
Context: ...ages: * Operator * Cluster Plugin * Helm Chart When the status of a packa...
(QB_NEW_EN)
🔇 Additional comments (18)
docs/en/ui/web_console/customize-left-navigation.mdx (3)
151-157: Confirm scope of backup_warehouse href (missing $cluster?)In the Backup & Recovery section,
backup_manageandrestore_manageuse$cluster/...whilebackup_warehouseuses a cluster-agnostic path. If the warehouse page is still cluster-scoped, it should likely include$clusterfor consistency.Do you intend
backup_warehouseto be global-scope? If not, consider:- - name: backup_warehouse - href: cluster-management/backup-restore/backup-warehouse + - name: backup_warehouse + href: $cluster/cluster-management/backup-restore/backup-warehouse
227-237: Verify DevOps Toolchain and Pipeline routesAdmin routes point to:
- Toolchain:
/console-devops/platform/integration- Pipelines:
/console-devops/platform/jenkins-custom-templateProject routes point to:
- Toolchain:
/console-devops/project/$project/integration- Pipelines:
/console-devops/project/$project/source-managementPlease confirm these are the latest and correct endpoints across versions (especially Pipeline paths).
Also applies to: 290-300
142-147: Gate + negate usage looks consistentUse of
gate: acp-safemodewithnegate: trueandpublicCloud: falseappears intentional and consistent across network items.Also applies to: 173-190
docs/en/ui/cli_tools/index.mdx (1)
8-11: Concise redirect looks goodThe page succinctly describes violet and redirects to the canonical “Upload Packages” doc. No issues.
docs/en/upgrade/upgrade_workload_cluster.mdx (2)
14-20: Call-outs for violet usage in DR context are appropriatePre-upgrade guidance to upload Extensions first, bulk upload link, and the standby
--dest-reponote all look good and align with the DR doc.
44-50: Verify external upgrade doc targetsPlease confirm these ExternalSiteLink targets and versions (AI 1.3, DevOps 4.0, Service Mesh 4.0) are correct for ACP 4.1 upgrade context.
docs/en/extend/upload_package.mdx (1)
118-127: Operator multi-cluster example is clearGood, concise demonstration of
--clustersusage and default behavior.docs/en/upgrade/overview.mdx (3)
6-13: Three-part upgrade framing and prerequisite order read wellClear separation of global, workload, and components, and the hard requirement to upgrade the global cluster first is aligned with typical control-plane/data-plane sequencing.
24-24: Anchor Verified in Target FileThe
#cluster_typeanchor exists on line 10 ofdocs/en/configure/clusters/overview.mdx(## Cluster Type {#cluster_type}), so the link is valid and no changes are needed.
18-20: Confirm “Functional Components” and “Upgrade” button labels match Web Console UIAll occurrences use the same terminology; please verify these labels match the current product screens to avoid doc/UX drift:
• docs/en/upgrade/overview.mdx (lines 18–19)
• docs/en/upgrade/upgrade_global_cluster.mdx (lines 66–67)
• docs/en/upgrade/upgrade_workload_cluster.mdx (lines 31–32)
• docs/en/gitops/upgrade/upgrade_gitops_plugin.mdx (lines 32–33)docs/en/upgrade/pre-upgrade.mdx (2)
6-9: Supported upgrade paths section looks goodThe scope is explicit (3.18→4.1, 4.0→4.1) and sets clear boundaries.
27-28: Good call-out on K8s 1.31 Pod restartsThe link to the upstream issue and the explicit restart expectation set proper expectations.
docs/en/upgrade/upgrade_global_cluster.mdx (6)
7-7: Global-first requirement is clearThis is consistent with control-plane-first upgrade strategy.
19-31: Image upload steps look correct for built-in vs external registriesCommand separation and options are clear.
58-62: Data Services warning is appropriateClear dependency note with a direct link.
144-149: Standby-first then primary sequencing is clearThe order is unambiguous and consistent with DR expectations.
174-186: Status check explanations are helpfulClear guidance on interpreting “missed” vs “surplus” keys.
107-115: Confirm uninstalling EtcdSync on the primary cluster for 3.18→4.1I didn’t find any prior upgrade guidance in the repo to verify this reversal of “standby-first” sequencing. Please confirm with engineering or the official runbook that uninstalling the EtcdSync plugin on the primary cluster first is required for upgrades from 3.18 to 4.1, and that no edge cases (e.g., asymmetric plugin versions) exist.
• File: docs/en/upgrade/upgrade_global_cluster.mdx
• Lines: 103–115
Corrected a typo in the global DR installation guide and updated post-upgrade links in the global cluster upgrade guide to point to versioned documentation paths.
1 participant
Summary by CodeRabbit