Describe the feature you'd like to have.
It should be possible to remove or replace a specific Gluster pod, maximally preserving affected data's resiliency.
What is the value to the end user? (why is it a priority?)
In certain deployment scenarios, it may be necessary to decommission an admin-specified Gluster node. Examples include:
In a deployment using DAS for Gluster bricks, the hosting server may need to be retired (hardware failure, lease expiration, etc).
For network-based storage, the backing storage system may need to be replaced/retired
How will we know we have a good solution? (acceptance criteria)
A particular Gluster pod instance can be targeted for decommissioning
Bricks are migrated off of the pod prior to it being taken offline
Once empty, the operator destroys the pod and associated South storage
Operator adjusts cluster sizing as necessary to account for the loss of the node (i.e., for fixed node count clusters, "manual mode", a new node would be created).
Describe the feature you'd like to have. It should be possible to remove or replace a specific Gluster pod, maximally preserving affected data's resiliency.
What is the value to the end user? (why is it a priority?) In certain deployment scenarios, it may be necessary to decommission an admin-specified Gluster node. Examples include:
How will we know we have a good solution? (acceptance criteria)
Additional context Requires state machine #17