Detach volume groups before deleting machine #460
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thunderboltsid
force-pushed
the
jira/NCN-101558
branch
from
aee8a8c to
bcc1ed5
Compare
This commit is a workaround to a known problem with hypervisor attached volumes that are created by CSI 3.0. Hypervisor attached volumes result in a volume group disk being attached to the VM on which the pod consuming the PV is running. When a cluster is deleted before deleting the PVC, the prism task fails to delete the VM because an existing volume group is attached to the VM. Since this problem is restricted to CSI 3.0 which relies on a minimum PC version of 2024.1 and the solution requires the volume group detach v4 API which is also available starting 2024.1, we make a v3 get prism central info call to fetch the PC version. If PC version is 2024 or greater we create a v4 client for the cluster as well. Before a machine is deleted, we check if the VM backing the machine has any disks backed by volume groups. If it does, we detach those volume groups before deleting the machine.
thunderboltsid
force-pushed
the
jira/NCN-101558
branch
from
bcc1ed5 to
8516a15
Compare
thunderboltsid
commented
Jul 25, 2024
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #460 +/- ##
==========================================
- Coverage 31.69% 29.35% -2.35%
==========================================
Files 14 14
Lines 1366 1475 +109
==========================================
Hits 433 433
- Misses 933 1042 +109 ☔ View full report in Codecov by Sentry. |
thunderboltsid
force-pushed
the
jira/NCN-101558
branch
from
103cda4 to
4926a09
Compare
|
as discussed, lets update https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/blob/main/scripts/csi_nutanix_update.sh as well or add a csi 3.0 specific one |
|
Also, as discussed, lets post the results of using a user with role "Kubernetes Infrastructure Provision" and try create/delete the cluster to verify if any permissions are required if possible |
dkoshkin
reviewed
Jul 25, 2024
thunderboltsid
force-pushed
the
jira/NCN-101558
branch
from
4926a09 to
ab38e14
Compare
deepakm-ntnx
approved these changes
Jul 26, 2024
|
/retest |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit is a workaround to a known problem with hypervisor attached volumes that are created by CSI 3.0. Hypervisor attached volumes result in a volume group disk being attached to the VM on which the pod consuming the PV is running. When a cluster is deleted before deleting the PVC, the prism task fails to delete the VM because an existing volume group is attached to the VM. Since this problem is restricted to CSI 3.0 which relies on a minimum PC version of 2024.1 and the solution requires the volume group detach v4 API which is also available starting 2024.1, we make a v3 get prism central info call to fetch the PC version. If PC version is 2024 or greater we create a v4 client for the cluster as well. Before a machine is deleted, we check if the VM backing the machine has any disks backed by volume groups. If it does, we detach those volume groups before deleting the machine.
How has this been tested?