New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to remove cstorVolumeReplicas after uninstall #2374
Comments
Hi @cjyar |
To get out of this -- And remove finalizers. |
@sonasingh46 Thanks for the help. After deleting the finalizers, the CVRs went away, and so did the namespace and the CRD. Yes, I deleted the PVC before deleting the OpenEBS namespace. It's possible that the PVC was never fully created, since it took me a while to get all the settings right. So the PVC may have been in a weird state when I deleted it. |
Thanks @cjyar for further explanations. |
From @gila, if there are multiple CVRs to be deleted:
|
…letion This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
…letion This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
…letion (#955) This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
This is documented. https://docs.openebs.io/docs/next/troubleshooting.html#cvr-deletion-unsuccessful |
…letion (openebs#955) This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
…letion (#955) This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
…letion (openebs#955) This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
…letion (#955) This commit removes the finalizers from a cstor volume replica object. This ensures removal of cstor volume replica object from kubernetes. In addition, it will try to delete the underlying volume if cvr controller gets the delete event. With the removal of finalizer there is no more retry mechanism to actually delete the underlying volume if there were issues encountered during earlier deletes. Why was finalizer put in first place? CstorVolumeReplica aliased CVR has finalizers that prohibits deletion unless the volume gets deleted. This is a check to ensure proper cleanup even if delete events are missed & / or underlying volume was not deleted in earlier attempts. Observations: There were observations that point to the fact that when the namespace (that contains these volumes) as well when the operator (that contains the CRD schema definitions) are deleted, CVR finalizers pose a significant problem to the overall deletion & later re-creation procedure. In fact the PODs that are responsible for actual volume deletion & confirming the delete status is no more available when its namespace or the openebs operator get deleted. Future Work: A better design needs to be implemented that ensures volume cleanup & hence space reclamation. fixes openebs/openebs#2374 fixes openebs/openebs#2349 Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
Description
After uninstalling OpenEBS according to the instructions at https://docs.openebs.io/docs/next/uninstall.html, the openebs namespace still contains 3 undeletable CVRs.
Expected Behavior
Removing the openebs namespace should have removed all the resources in it, including these CVRs.
Current Behavior
Detail on one of those CVRs:
Steps to Reproduce
Hard to say. I installed OpenEBS from the operator ("kubectl") instructions, played around with it for a while, and then followed the uninstall instructions.
Your Environment
/etc/os-release
): 16.04.5 LTS (Xenial Xerus)uname -a
): 4.4.0-141-generic Vagrant up seems to be stuck indefinitely #167-Ubuntu x86_64The text was updated successfully, but these errors were encountered: