anthill
anthill copied to clipboard
Replacement of a specific Gluster node
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).
Additional context Requires state machine #17