Update DCS persistent disk isThin guidance

docs/en/create-cluster/huawei-dcs.mdx

@@ -238,7 +238,7 @@ Follow these steps in order to provision a functional cluster (control plane **a
 
 **Note**: Infrastructure resources (Secret, control-plane `DCSIpHostnamePool`, control-plane `DCSMachineTemplate`) should be configured separately. See [Infrastructure Resources for Huawei DCS](../infrastructure/huawei-dcs.mdx) for instructions.
 
-If you need any disk to survive rolling replacement, declare it in the matching `DCSIpHostnamePool.spec.pool[].persistentDisk` entry. This includes the platform-required `/var/cpaas` disk.
+If you need any disk to survive rolling replacement, declare it in the matching `DCSIpHostnamePool.spec.pool[].persistentDisk` entry. This includes the platform-required `/var/cpaas` disk. The provider creates new persistent volumes as independent persistent normal volumes. When the DCS environment requires an explicit thin-provisioning setting, set `persistentDisk[].isThin`; if you omit it, the provider does not send `isThin` and DCS uses the platform default.
 
 ### Resolving Placeholder Values \{#resolving-placeholders}
 

docs/en/global/upgrade.mdx

@@ -89,6 +89,8 @@ spec:
             - defaults
 ```
 
+Use `isThin` only when the DCS environment requires an explicit thin-provisioning value. If omitted, the provider does not send `isThin` and DCS uses the platform default. New persistent volumes are created as independent persistent normal volumes.
+
 Use the IP pool status to confirm that preserved disks are detached from old VMs and attached to replacement VMs during the rolling replacement.
 
   </Tab>

docs/en/how-to/dcs_persistent_disk_upgrade.mdx

@@ -34,7 +34,7 @@ The current model moves upgrade-preserved disks into `DCSIpHostnamePool.spec.poo
 1. Claims the existing disk from the old VM.
 2. Safely stops the old VM.
 3. Detaches the disk.
-4. Converts stock volumes to independent shared volumes when needed.
+4. Converts stock volumes to independent persistent volumes when needed.
 5. Deletes the old VM.
 6. Reattaches the disk to the replacement VM.
 7. Boots the replacement VM, which mounts the existing filesystem without reformatting it.
@@ -161,6 +161,8 @@ The spec interacts with the live disk attributes in three ways:
 - `datastoreName` or `datastoreClusterName` — must point to the same storage target as the live disk
 - `pciType` — must match the live disk PCI type. If omitted, the provider uses the default `VIRTIO`; verify the live disk PCI type before omitting this field, because a non-`VIRTIO` live disk can fail the strict claim match
 
+`isThin` is creation-only. It is sent only when the provider creates a new DCS persistent volume. It is not compared during existing-volume claim and does not convert existing volumes.
+
 **Filesystem (affects guest-side initialization, not the claim check):**
 
 - `format` — used only when initializing a fresh disk. If the live disk already has a filesystem, the existing format is preserved and `mkfs` is skipped.
@@ -248,7 +250,7 @@ kubectl get dcsiphostnamepool <iphostname-pool-name> -n cpaas-system -o yaml
 During the transition, each record appears under `status.persistentDiskStatus`. The stable phases to watch for are:
 
 - `phase: Attached` while the old VM still owns the disk
-- `phase: Available` after the disk is detached (and converted from a stock volume to an independent shared volume when needed)
+- `phase: Available` after the disk is detached (and converted from a stock volume to an independent persistent volume when needed)
 - `phase: Attached` again after the replacement VM reattaches the disk
 
 Transient phases (`Attaching`, `Detaching`) may briefly appear during the corresponding operations; `Deleting` appears when a disk is being permanently removed, for example during pool or cluster cleanup. The full phase set is `Creating`, `Available`, `Attaching`, `Attached`, `Detaching`, `Deleting`, `Error`.

docs/en/infrastructure/huawei-dcs.mdx

@@ -331,6 +331,7 @@ spec:
 | `slot` | Disk position within the IP slot. It determines attach order, guest device naming, and the sequence number used during volume claim and reattach. |
 | `quantityGB` | Disk size in GB. |
 | `datastoreName` / `datastoreClusterName` | Specify exactly one storage target for the persistent disk. |
+| `isThin` | Optional. Controls DCS thin provisioning for newly created persistent volumes. If omitted, the provider does not send `isThin` and DCS uses the platform default. |
 | `path` | Mount path inside the guest OS. `/var/cpaas` is the platform-required path. |
 | `format` | Filesystem used when the disk is first initialized. If the replacement VM sees an existing filesystem, formatting is skipped. |
 | `options` | `mkfs` options applied only when the disk is first formatted. |
@@ -340,9 +341,10 @@ spec:
 **Update rules:**
 
 - You can append new `persistentDisk` entries to an existing IP slot. The controller attaches the newly added disk to the running VM on the DCS side, but it does not format or mount the disk inside the guest OS. Guest formatting and mounting take effect only after the VM is replaced and the replacement VM runs the generated disk setup during bootstrap.
+- The controller creates new persistent volumes as independent persistent normal volumes. When it reuses an existing volume, it only requires the volume to be independent and persistent; it does not require a specific DCS volume type.
 - Do not delete existing `persistentDisk` entries from the spec. The webhook rejects removal.
 - Treat `format`, `options`, and `pciType` as immutable after creation.
-- Treat `quantityGB` and datastore changes as rollout-sensitive changes. The webhook performs best-effort platform validation when the pool carries a cluster label.
+- Treat `quantityGB` and datastore changes as rollout-sensitive changes. The webhook performs best-effort platform validation when the pool carries a cluster label. `isThin` is creation-only: changing it does not validate, reconcile, or convert existing volumes, and affects only persistent volumes created later.
 - Treat `path` and `mountOptions` changes as guest-side changes that take effect on replacement machines during rolling updates.
 
 ---

docs/en/manage-nodes/huawei-dcs.mdx

@@ -197,8 +197,10 @@ Declare any upgrade-preserved disk in the matching `DCSIpHostnamePool.spec.pool[
 - On replacement nodes, the guest disk setup logic checks for an existing filesystem. If the disk is already formatted, it skips `mkfs` and mounts the disk directly.
 - Persistent-disk workflows require one-by-one replacement, so keep `MachineDeployment.spec.strategy.rollingUpdate.maxSurge = 0`.
 - You can append new `persistentDisk` entries, but deleting existing entries is not supported. The controller attaches the newly added disk to the running VM on the DCS side, but it does not format or mount the disk inside the guest OS. Guest formatting and mounting take effect only after the VM is replaced and the replacement VM runs the generated disk setup during bootstrap.
+- The controller creates new persistent volumes as independent persistent normal volumes. When it reuses an existing volume, it only requires the volume to be independent and persistent; it does not require a specific DCS volume type.
 - Treat `format`, `options`, and `pciType` as immutable after creation.
-- Treat `quantityGB` and datastore changes as rollout-sensitive changes. The webhook performs best-effort validation against the DCS platform when it has enough cluster context.
+- Use `isThin` only when the DCS environment requires an explicit thin-provisioning value for newly created persistent volumes. If omitted, the provider does not send `isThin` and DCS uses the platform default.
+- Treat `quantityGB` and datastore changes as rollout-sensitive changes. The webhook performs best-effort validation against the DCS platform when it has enough cluster context. `isThin` is creation-only: changing it does not validate, reconcile, or convert existing volumes, and affects only persistent volumes created later.
 
 To inspect the runtime state of persistent disks during node operations, check `status.persistentDiskStatus` on the pool:
 
@@ -481,7 +483,7 @@ Increase the number of worker nodes to handle increased workload or add new capa
    **Important Notes**
    - The `pool` array must include **all existing entries** plus the new entries you want to add
    - Copy the existing entries from the exported YAML to avoid data loss
-   - `kubectl patch --type='merge'` replaces the entire `spec.pool` array, so copy every existing `persistentDisk` block unchanged unless you are intentionally adding new disks
+   - `kubectl patch --type='merge'` replaces the entire `spec.pool` array, so copy every existing `persistentDisk` block unchanged, including `isThin` if it is present, unless you are intentionally adding new disks
    - Ensure each new entry has unique `ip`, `hostname`, and `machineName` values
    - If new worker nodes also need the platform-required `/var/cpaas` disk, declare it in each new entry's `persistentDisk`
    - Network parameters (`mask`, `gateway`, `dns`) typically match existing entries

package.json

@@ -1,6 +1,6 @@
 {
   "devDependencies": {
-    "@alauda/doom": "^2.5.1"
+    "@alauda/doom": "^2.5.2"
   },
   "scripts": {
     "dev": "doom dev",