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
To get Replace done we need to have support for 'Remove' storage first.
Considering we already support 'update' of storage through Operator's MODIFY handle, a single node replace when the storage is of type Replica3. Lets focus on this feature through distribution count addition deletion.
To support remove-brick force, we can just do storage config update with storage config removed. [Already possible]
To support remove-brick with data migration, we need to perform two steps : A way to let operator (and inturn the volfile generator) know that a given storage is 'not-active' (or decommissioned). Once this is done, the distribute translator doesn't send the write/create request to that node anymore.
Now, provide an option to trigger migration. (can be automated, but i recommend having it as an script initially, and then automate it).
Once migration is complete, update storage-config again by removing the storage completely now [Already possible].
Please note that this means, we are adding another 'option' to storage-config, and hence issues like #533 may crop up if we don't handle version properly (but if we do this well before 0.9.0, considering we already have added Disperse and few other changes, it can be included in the same version).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
More on this usecase in #536.
To get Replace done we need to have support for 'Remove' storage first.
Considering we already support 'update' of storage through Operator's MODIFY handle, a single node replace when the storage is of type Replica3. Lets focus on this feature through distribution count addition deletion.
To support remove-brick force, we can just do storage config update with storage config removed. [Already possible]
To support remove-brick with data migration, we need to perform two steps : A way to let operator (and inturn the volfile generator) know that a given storage is 'not-active' (or
decommissioned
). Once this is done, the distribute translator doesn't send the write/create request to that node anymore.Now, provide an option to trigger migration. (can be automated, but i recommend having it as an script initially, and then automate it).
Once migration is complete, update storage-config again by removing the storage completely now [Already possible].
Please note that this means, we are adding another 'option' to storage-config, and hence issues like #533 may crop up if we don't handle version properly (but if we do this well before 0.9.0, considering we already have added Disperse and few other changes, it can be included in the same version).
Beta Was this translation helpful? Give feedback.
All reactions