rustfs/scripts/test/decommission_validation.md

Decommission Validation

This helper covers a practical decommission smoke flow against a disposable multi-pool cluster that is already running and reachable via mc.

What It Covers

• Versioned object rewrite
• Multipart object rewrite
• Delete-marker preservation
• Object-lock bucket readability after decommission
• Admin decommission start/status/cancel command flow

What It Does Not Cover Automatically

• Remote tier object migration
• Lifecycle-expired object skipping
• Replication target side-effects
• Cross-node failure injection during decommission

Those scenarios still need cluster-specific setup and should be verified manually after the smoke flow passes.

Prerequisites

• mc installed and configured with an alias that points to the RustFS cluster
• A disposable cluster with at least two pools
• A pool cmdline string that matches the admin API input, for example: http://server{5...8}/disk{1...4}

Recommended Flow

1. Prepare data: ./scripts/test/decommission_validation.sh prepare <alias>
2. Start decommission: ./scripts/test/decommission_validation.sh start <alias> '<pool-cmdline>'
3. Wait for completion: ./scripts/test/decommission_validation.sh wait <alias> '<pool-cmdline>' 900
4. Verify readable data and version listings: ./scripts/test/decommission_validation.sh verify <alias>

Optional Cancel Check

1. Start decommission on a disposable pool.
2. Run: ./scripts/test/decommission_validation.sh cancel <alias> '<pool-cmdline>'
3. Confirm status shows canceled=true and not complete=true.

Manual Extension For Tiered Objects

If the cluster already has a configured remote tier and ILM transition rule:

1. Upload an object that matches the transition rule.
2. Wait until the object is transitioned remotely.
3. Run the decommission flow above.
4. Confirm:
   • the object is still readable after decommission
   • decommission completes without failed=true
   • no residual object/version remains on the source pool