Pool Lifecycle Operations

Explore this Page

Overview

Pool Lifecycle Operations in DataCore Puls8 provide a comprehensive set of controls for managing the full lifecycle of Replicated PV Mayastor storage pools from temporary isolation during maintenance to permanent removal when a pool is no longer required or cannot be recovered.

By cordoning a pool, you can temporarily stop the creation of new replicas, snapshots, restores, or imports on that pool while existing data and services continue to operate normally. This controlled isolation helps avoid unexpected replica placement on pools that are under investigation, nearing capacity, or scheduled for hardware upgrades. When maintenance is complete, uncordoning the pool restores normal scheduling behavior.

DataCore Puls8 also supports multiple methods for deleting storage pools, depending on the state of the pool and the preferred management workflow. Online pools that are empty can be deleted using the kubectl-puls8 plugin or by deleting the corresponding DiskPool custom resource (CR). Pools that are no longer reachable or cannot be recovered can be removed through a purge operation, also referred to as offline pool deletion.

This document covers all pool lifecycle operations available in DataCore Puls8, including cordoning, uncordoning, and deleting pools using the kubectl-puls8 plugin or DiskPool custom resources, along with the available options, recommended use cases, and key operational considerations.

Requirements

Before performing any pool lifecycle operation, ensure the following requirements are met:

  • DataCore Puls8 Installation with Replicated PV Mayastor Enabled: You must have DataCore Puls8 installed on your Kubernetes cluster with Replicated PV Mayastor enabled. Refer Installing DataCore Puls8 Documentation for more information.
  • kubectl puls8 Plugin Installed: Ensure that the kubectl-puls8 plugin is installed and configured with the appropriate access to your DataCore Puls8 cluster.

Cordon a Pool

When you cordon a pool, you prevent new resources of the specified types from being scheduled on that pool. This allows you to safely isolate the pool while performing maintenance, troubleshooting, or preparing it for decommissioning. Existing data on the pool remains fully available and continues to serve workloads.

Use the kubectl-puls8 mayastor plugin to cordon a pool and block new replicas, snapshots, restores, or imports from being scheduled on it.

Copy
Cordon a Pool to Block New Replicas
kubectl-puls8 mayastor cordon pool <pool-name> --replicas
Copy
Cordon a Pool to Block New Replicas and Imports
kubectl-puls8 mayastor cordon pool <pool-name> --replicas --imports

Flags

  • --replicas - Prevent new replicas from being created on the pool
  • --snapshots - Prevent new snapshots from being scheduled
  • --restores - Prevent new restore operations on the pool
  • --imports - Prevent pool import operations.

Uncordon a Pool

When you uncordon a pool, you remove the scheduling restrictions and allow new resources to be created again. Use this when maintenance is complete or when you want the pool to resume normal operations.

Copy
Uncordon a Pool to Re-enable Replica and Import Scheduling
kubectl-puls8 mayastor uncordon pool <pool-name> --replicas --imports

Flags

  • The same flags apply as with cordon, letting you selectively enable scheduling for replicas, snapshots, restores, and imports.
  • By default, running uncordon pool without flags will remove all existing cordons, restoring full scheduling for the pool.

Delete Pools (Online)

An online pool can be deleted when it is accessible and no longer required. Before deleting an online pool, ensure that the pool is empty and does not contain any volume replicas or snapshots. Pool deletion is blocked while dependent resources exist on the pool.

Copy
Delete an Empty Online Pool
kubectl-puls8 mayastor delete pool <pool-name> -n <namespace> --yes

Use the following commands to remove the DiskPoolClaim / DiskPool custom resource (CR) for the pool:

Copy
Delete DiskPoolClaim/DiskPool CR
kubectl -n puls8 delete dpc <pool-name> --wait=false && \
kubectl -n puls8 patch dpc <pool-name> --type=merge -p '{"metadata":{"finalizers":null}}'
kubectl-puls8 mayastor delete pool <pool-name> -n <namespace> --yes --cleanup-dsp

Online pool deletion is supported only for empty pools. Remove or relocate all replicas and snapshots before attempting to delete the pool.

Delete Pools (Offline)

Offline pool deletion, referred to as purge, removes an irrecoverable pool's representation from the DataCore Puls8 Replicated PV Mayastor control plane when the pool is no longer reachable and cannot be recovered. Purge removes the pool from the control plane without requiring access to the underlying storage device.

This operation is intended for failure scenarios where the pool is considered irrecoverably lost and cannot be deleted through normal means. Typical scenarios for pool purge include:

  • The host running the pool is permanently unavailable and has been replaced.
  • The underlying storage device is no longer accessible.
  • The pool cannot be recovered due to infrastructure or hardware failure.

Offline pool deletion is irreversible and may result in permanent loss of access to volume or snapshot data if the purged pool contains the last healthy replicas. Purge is not part of the normal pool lifecycle and should be used only when you are certain that the pool cannot be recovered.

Before performing purge, ensure that:

  • The pool is offline.
  • The pool is cordoned to prevent new replicas or snapshots from being scheduled on it.

Before purge, cordon the pool to prevent new replicas or snapshots from being scheduled.

Copy
Example: Cordon the Pool
kubectl-puls8 mayastor cordon pool <pool-name> -n <namespace> --replicas --snapshots
Copy
Sample Output
Pool <pool-name> cordoned successfully. Current constraints: replicas,snapshots

When to Use Purge

Use purge only when:

  • The pool is no longer accessible and cannot be recovered.
  • The host running the pool is permanently unavailable.
  • The underlying storage device is lost or inaccessible.

Do not use purge for temporary failures or conditions where the pool may become available again.

Verify the Pool State

Before proceeding, confirm that the target pool is in an Offline state.

Copy
Get Pool Status
kubectl-puls8 mayastor get pools -n puls8
Copy
Sample Output
ID                  DISKS                                            MANAGED  NODE           STATUS                   ALERTS   CAPACITY  ALLOCATED  AVAILABLE  COMMITTED  ENCRYPTED  DISK-CAPACITY  MAX-EXPANDABLE-SIZE  VOLUMES  SNAPSHOTS
pool-node-0-469894  aio:///dev/disk/by-id/scsi-0HC_Volume_105758064  true     node-0-469894  Online                   Healthy  10 GiB    4 GiB      6 GiB      4 GiB      false      10 GiB         127.8 GiB            1        0
pool-node-1-469894  /dev/disk/by-id/scsi-0HC_Volume_105758065        true     node-1-469894  Offline (NodeIsOffline)  <none>   0 B       0 B        0 B        <none>     false      <none>         <none>               2        0
pool-node-2-469894  aio:///dev/disk/by-id/scsi-SHC_Volume_105758063  true     node-2-469894  Online                   Healthy  10 GiB    4 GiB      6 GiB      4 GiB      false      10 GiB         127.8 GiB            1        0

Review Purge Impact

Before performing purge, review the affected replicas and volumes.

Copy
Review Purge Impact
kubectl-puls8 mayastor delete pool <pool-name> -n <namespace> --purge --show-impact
Copy
Sample Output
POOL                STATUS   CORDON  REPLICAS  VOLUMES                               READY
pool-node-1-469894  Unknown  Ready   1         86598b37-4a37-4a85-a014-4f5e5022bb4e  true

Purge a Pool (Offline)

Use the following command to purge an irrecoverable pool from the DataCore Puls8 Replicated PV Mayastor control plane.

Copy
Purge a Pool (Offline)
kubectl-puls8 mayastor delete pool <pool-name> -n puls8 --purge --yes

Use the following commands to remove the DiskPoolClaim/DiskPool custom resource (CR) for the pool.

Copy
Delete DiskPoolClaim/DiskPool CR
kubectl -n puls8 delete dpc <pool-name> --wait=false && \
kubectl -n puls8 patch dpc <pool-name> --type=merge -p '{"metadata":{"finalizers":null}}'
kubectl-puls8 mayastor delete pool <pool-name> -n puls8 --purge --yes --cleanup-dsp

Purge Options

If the pool contains critical data, additional confirmation flags may be required.

Condition Required Flag
General confirmation for the purge operation --yes
Accept data loss for replicas that are the last healthy replicas of their respective volumes on the pool --accept-volume-loss
Accept data loss for snapshot replicas that are the last remaining snapshot replicas of their respective volumes on the pool. Can only be used together with --accept-volume-loss --accept-snapshot-loss
Accept both volume and snapshot data loss using a single flag --accept-data-loss
Remove DiskPool CRs associated with the purged pool --cleanup-dsp
Display the expected volume and snapshot impact before performing purge --show-impact

Data Loss Confirmation

If the purge operation impacts the last healthy replica of a volume, the following message is displayed:

Copy
Data Loss Warning Message
Volumes would lose their last healthy replica. Use --accept-volume-loss to proceed,
or --accept-data-loss to also accept snapshot loss in a single flag.

To continue the purge operation with data loss acknowledged:

Copy
Purge a Pool with Data Loss Confirmation
kubectl-puls8 mayastor delete pool <pool-name> -n <namespace> --purge --yes --accept-data-loss
Copy
Sample Output
POOL                VOLUME-LOSS  SNAPSHOT-LOSS
pool-node-1-469894  1 volume(s)  <none>

Impact on Workloads

Volume Type Impact
Single-replica volumes Data is permanently lost if the replica resides on the purged pool.
Multi-replica volumes Volumes may continue to operate and recover using remaining replicas if high availability (HA) is configured and sufficient replicas remain.
Snapshots Snapshots may become unusable if the last healthy snapshot replica was located on the purged pool.

Verify Purge Completion

After purge, verify that the pool has been removed and that affected workloads reflect the updated state.

Copy
Verify Pool Removal
kubectl-puls8 mayastor get pools

Expected Results

  • The purged pool is no longer listed.
  • Affected volumes may show updated states.

Delete Pools Using a DiskPool CR

You can also delete pools by operating directly on the associated DiskPool custom resource (CR).

Delete Online Pools

To delete an online pool using its DiskPool resource, delete the corresponding DiskPool CR. The pool must be empty and must not contain any volume replicas or snapshots.

Copy
Delete an Online Pool Using a DiskPool CR
kubectl delete dsp <pool-name> -n <namespace>

Deletion of an online DiskPool resource is supported only when the pool does not contain replicas or snapshots.

Purge Offline Pools

For an offline pool, add a deletion annotation to the DiskPool resource. The annotation indicates that a purge operation should be performed and confirms acceptance of replica and snapshot loss associated with the pool.

Copy
Purge an Offline Pool Using a DiskPool CR Annotation
kubectl -n <namespace> annotate dsp <pool-name> \
  openebs.io/delete-opts='purge=true,accept=true' \
  --overwrite

Annotation Options

Option Description
purge=true Performs a purge operation on the pool
accept=true Confirms deletion of replicas and snapshots associated with the pool
accept-volume-loss=true Accepts permanent loss of affected volume replicas
accept-snapshot-loss=true Accepts permanent loss of affected snapshot replicas
accept-data-loss=true Accepts both volume and snapshot data loss

If deleting the pool would result in permanent loss of volume replicas or snapshots, additional confirmation options are required.

Copy
Example: Accept Volume and Snapshot Data Loss
kubectl -n <namespace> annotate dsp <pool-name> \
  openebs.io/delete-opts='purge=true,accept=true,accept-data-loss=true' \
  --overwrite
Copy
Example: Shorthand Syntax
kubectl -n <namespace> annotate dsp <pool-name> \
  openebs.io/delete-opts=purge-accept-all \
  --overwrite

Purging a pool through a DiskPool resource is irreversible and may result in permanent volume or snapshot data loss if the pool contains the last healthy replicas.

Typical Use Cases

  • Planned Maintenance: Isolate a pool before firmware upgrades or hardware replacement.
  • Capacity Management: Prevent new replicas on a pool nearing its operational threshold.
  • Controlled Decommissioning: Cordon, migrate replicas, and then retire the pool.

Best Practices

  • Cordoning does not move existing replicas. It only blocks new scheduling.
  • Verify sufficient uncordoned pools are available to maintain redundancy.
  • Document each cordon action in your change-management system and uncordon promptly after maintenance.

Benefits of Pool Cordon and Delete Operations

  • Controlled Maintenance: Temporarily prevent new workloads on a pool during upgrades or troubleshooting.
  • Improved Reliability: Avoid placing new replicas on pools with capacity or performance issues.
  • Safe Decommissioning: Isolate a pool while migrating or scaling replicas to other pools.
  • Operational Flexibility: Choose which resource types replicas, snapshots, restores, imports are affected.
  • Business Continuity: Keep applications running smoothly during maintenance or investigations.
  • Safe Pool Removal: Delete online pools cleanly when they are empty and no longer required.
  • Offline Pool Recovery: Remove irrecoverable pools from the control plane after host, storage, or infrastructure failures without requiring access to the underlying storage device.

Learn More