You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 30, 2020. It is now read-only.
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
The text was updated successfully, but these errors were encountered: