docs: update ACP 4.3 upgrade guidance (#622)

* docs: update ACP 4.3 upgrade guidance

* docs: clarify cluster plugin lifecycle wording

---------

Co-authored-by: MeoK <12069138+chinameok@users.noreply.github.com>

Author: chinameok

docs/en/extend/cluster_plugin.mdx

@@ -27,7 +27,7 @@ Plugins are published via the **violet** tool. Note:
 To view all plugins provided by the platform:
 
 1. Navigate to the platform management view.
-2. Click the left navigation menu: **Administrator** > **Marketplace** > **Cluster Plugin**
+2. Click the left navigation menu: **Administrator** > **Marketplace** > **Cluster Plugins**
 
 This page lists all available plugins along with their current status.
 
@@ -255,6 +255,20 @@ Field explanations are the same as non-config.
 
 
 
+## Cluster plugin life cycle values
+
+The **Cluster Plugins** page uses the `cpaas.io/lifecycle-type` label to indicate how a cluster plugin is maintained and upgraded. If the label is absent, the plugin is treated as `Agnostic`.
+
+In this context, `Core` means the plugin follows the ACP Core release and upgrade cycle together with the cluster Distribution Version.
+
+The **Cluster Plugins** list page shows a **Life cycle** column and provides a **Life cycle** filter so you can quickly identify each plugin type.
+
+| Life cycle | Description | Upgrade path |
+| --- | --- | --- |
+| `Core` | The plugin follows the ACP Core release and upgrade cycle together with the cluster Distribution Version and does not support standalone upgrade. | Upgrade the cluster to update the plugin. |
+| `Aligned` | The plugin follows the ACP release stream but can still be updated independently when a newer plugin version is published. | Upgrade the plugin from the Cluster Plugins list page or details page. |
+| `Agnostic` | The plugin is released independently from ACP. | Upgrade the plugin from the Cluster Plugins list page or details page. |
+
 ## Upgrade Process
 
 To upgrade an existing plugin to a newer version:
@@ -270,10 +284,20 @@ To upgrade an existing plugin to a newer version:
    * Switch to the **Cluster Plugin** tab
    * The plugin details will show the newly uploaded version
 
-3. Perform the upgrade:
+3. Review the plugin:
+
+   * Navigate to **Administrator** > **Marketplace** > **Cluster Plugins**
+   * Select the target cluster
+   * Review the plugin from the list page or open the plugin details page
+
+4. Perform the upgrade:
+
+   * If the plugin uses the `Aligned` or `Agnostic` life cycle, start the standalone upgrade from the list page or details page
+   * The platform upgrades the installed plugin to a newer published version
+
+5. Handle `Core` plugins:
+
+   * `Core` plugins do not support standalone upgrades
+   * When a newer version is detected, the plugin details page shows a reminder to upgrade the cluster instead
 
-   * Navigate to **Administrator** > **Clusters** > **Clusters**
-   * Clusters with upgradable plugins will display an upgrade icon
-   * Enter the cluster details and switch to the **Features** tab
-   * The upgrade button will be enabled under the features component
-   * Click **Upgrade** to complete the plugin upgrade
+**Note:** `Upgrade` changes the installed plugin version. `Update` remains a plugin-specific action for changing configuration or running plugin-defined update logic.

docs/en/overview/release_notes.mdx

@@ -32,6 +32,12 @@ ACP CLI also introduces upgrade-oriented administrator commands such as `ac adm
 
 For operational guidance, see [Upgrade](/upgrade/index.mdx).
 
+#### Standalone Cluster Plugin Upgrade
+
+ACP 4.3 adds standalone upgrade support for cluster plugins that use the `Aligned` or `Agnostic` life cycle.
+
+The **Cluster Plugins** page now shows the plugin life cycle, and eligible plugins can be upgraded independently from the list page or details page. `Core` plugins continue to follow cluster upgrades.
+
 #### MicroOS-Based Global Clusters on Huawei DCS
 
 ACP 4.3 allows administrators to create the `global` cluster on Huawei DCS with MicroOS-based immutable infrastructure. This extends the immutable operating model from workload clusters to platform installation scenarios on DCS.

docs/en/upgrade/overview.mdx

@@ -5,6 +5,8 @@ weight: 10
 
 ACP 4.3 uses a Cluster Version Operator (CVO)-based workflow for cluster upgrades.
 
+In the Web Console, the upgrade request now follows a two-step flow: review RPCH items first, and then submit the upgrade request in a separate confirmation step.
+
 When moving the platform to a new ACP Distribution Version, the upgrade normally proceeds in two stages:
 
 1. Upgrade the global tier to the target Distribution Version by following the validated global-cluster procedure, including artifact preparation and preflight checks.
@@ -17,16 +19,16 @@ A workload cluster can be upgraded only to a Distribution Version that the globa
 - **ClusterVersionShadow (`cvsh`)**: The upgrade resource used to track current version, desired version, preflight results, execution stages, and history.
 - **Distribution Version**: The ACP version currently reached by a cluster. A workload cluster can be upgraded only to a Distribution Version that the global tier has already reached.
 - **Preflight**: Validation checks that run before the upgrade starts applying the target version. For workload clusters, review preflight results from the upgrade status output after the upgrade request is submitted.
-- **Available upgrade targets**: The upgrade versions that are currently offered for a cluster. For workload clusters, target versions are typically offered only after the global tier has already reached the same Distribution Version.
+- **Available upgrade targets**: The upgrade versions that are currently offered for a cluster. In the Web Console, the target version for the current upgrade flow is determined by the platform.
 - **upgrade.sh**: The preparation script that uploads artifacts and deploys or updates the cluster version operator before the upgrade proceeds.
 - **Global DR environment**: An environment with both a primary global cluster and a standby global cluster.
 - **Primary global cluster**: The global cluster that the platform access domain currently resolves to.
 - **Standby global cluster**: The other global cluster in the DR pair. After a failover, the roles of the two clusters are swapped.
 
 ## Upgrade Entry Points
 
-- **Global clusters**: Follow the validated `upgrade.sh`-based procedure. After the preparation phase completes, request the upgrade from the Web Console, use ACP CLI, or update `ClusterVersionShadow.spec.desiredUpdate` directly.
-- **Workload clusters**: Use the Web Console or ACP CLI after the target version becomes available for the workload cluster.
+- **Global clusters**: Follow the validated `upgrade.sh`-based procedure. After the preparation phase completes, request the upgrade from the Web Console through the two-step RPCH review flow, use ACP CLI, or update `ClusterVersionShadow.spec.desiredUpdate` directly.
+- **Workload clusters**: Use the Web Console through the two-step RPCH review flow or use ACP CLI after the target Distribution Version becomes available for the workload cluster.
 
 ## Related Documentation
 

docs/en/upgrade/upgrade_global_cluster.mdx

@@ -134,6 +134,16 @@ After the preparation phase completes, choose one of the following entry points:
 * Patch `ClusterVersionShadow.spec.desiredUpdate` directly when you need to operate the underlying CVO resource.
 * Use ACP CLI to request the upgrade for `global` explicitly.
 
+If you use the Web Console, the request follows a two-step flow:
+
+* In **Step 1**, review the RPCH list.
+* Click **Acknowledge** to continue to **Step 2**.
+* In **Step 2**, review **Current Version** and **Target Version**. The page does not display a plugin list or a warning panel at this stage.
+* The target version is determined by the prepared upgrade artifacts and cannot be selected manually in the Web Console.
+* Click **Start Upgrade**.
+* Confirm the action in the dialog.
+* After confirmation, the page shows that the upgrade request has been submitted and the action enters an in-progress state.
+
 `kubectl` example:
 
 ```bash

docs/en/upgrade/upgrade_workload_cluster.mdx

@@ -19,9 +19,9 @@ ACP 4.3 uses the same CVO-based workflow for workload clusters as for the `globa
 
 Before requesting the upgrade, verify that:
 
+* The workload cluster version is lower than the current `global` cluster version.
 * The global tier has already reached the target ACP Distribution Version.
 * In global DR environments, both the standby and primary global clusters have already reached that target Distribution Version.
-* The target version is available for the workload cluster.
 
 ### Run preflight checks
 
@@ -44,18 +44,21 @@ For preflight block handling patterns, see [Handle preflight blocks when needed]
 
 ### Request the upgrade
 
-After preflight passes and the target version is available for the workload cluster, choose one of the following entry points:
+After preflight passes, choose one of the following entry points:
 
-* Request the target version from the Web Console on the workload cluster details page.
+* Start the upgrade from the workload cluster in the Web Console.
 * Use ACP CLI when your current ACP session can access the target workload cluster. To avoid ambiguity, specify the target cluster explicitly with `--cluster`.
 
 If you are new to ACP CLI, see [Getting Started with ACP CLI](/ui/cli_tools/ac/getting-started.md). For session and cluster selection, see [Managing CLI Profiles](/ui/cli_tools/ac/managing-cli-profiles.md).
 
-Web Console path:
+If you use the Web Console, the request follows a two-step flow:
 
-```text
-Administrator > Clusters > Clusters > <workload cluster> > Functional Components
-```
+* In **Step 1**, review the RPCH list.
+* Click **Acknowledge** to continue to **Step 2**.
+* In **Step 2**, review **Current Version** and **Target Version**. The page does not display a plugin list or a warning panel at this stage.
+* The target version is the current `global` cluster version and cannot be selected manually in the Web Console.
+* Click **Start Upgrade**.
+* After the request is submitted, the page shows that the upgrade request has been submitted and the action enters an in-progress state.
 
 ACP CLI example: