[cinder-csi-plugin] Validate volume status before attach#3129
Conversation
|
Hi @hemna. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Check that a volume is in an acceptable state before calling the Nova attach API: - For regular (single-attach) volumes: status must be 'available' - For multi-attach capable volumes: status must be 'available' or 'in-use' - migration_status must not be 'migrating' Previously the driver would blindly call volumeattach.Create regardless of volume status, relying on Nova/Cinder to reject the request. This produced opaque errors that made troubleshooting difficult and generated unnecessary API calls for volumes in transitional states (creating, downloading, detaching, etc.). The migration_status check prevents attempting to attach a volume that is actively being migrated, which would fail with an opaque error from Cinder. A custom volumeForAttach struct is used to extract migration_status from the Cinder API response, since gophercloud's Volume struct does not map this field. With this change the driver returns immediate, descriptive errors when the volume is not attachable, allowing the CO (external-attacher) to retry with exponential backoff via standard CSI error handling.
0d1429c to
f8d4aa4
Compare
What this PR does / why we need it:
AttachVolumenow validates that the volume is in an acceptable state before calling the Nova volume attach API.availableavailableorin-usemigration_statusmust not bemigratingPreviously, the driver would call
volumeattach.Createregardless of volume status, relying on Nova/Cinder to reject the request. This produced opaque 409 Conflict errors that made troubleshooting difficult and generated unnecessary API calls for volumes in transitional states (e.g.,creating,downloading,detaching).Additionally, a volume can have status
availablewhile actively being migrated (migration_status: migrating). Attempting to attach in this state would fail with an opaque Cinder error. The driver now checks this explicitly.With this change the driver returns immediate, descriptive errors when the volume is not attachable, allowing the CO (external-attacher) to retry with exponential backoff via standard CSI error handling.
How it works:
A custom
volumeForAttachstruct is used to extract both the standard volume fields andmigration_statusfrom the Cinder API response in a single API call. This is necessary because gophercloud'sVolumestruct does not map themigration_statusfield.The validation is placed inside
AttachVolume(after the existing idempotency check for already-attached volumes). This means:GetVolumecall)Which issue this PR fixes (if applicable):
Related to #3124
Special notes for reviewers:
This is a simpler alternative to the polling/waiting approach in #3124. Rather than adding a wait-loop with poll intervals and context deadline handling, this PR fails fast with a clear error and lets the CO handle retries — which it already does via exponential backoff.
The
DetachVolumefunction already performs similar status validation (lines 307-318 ofopenstack_volumes.go), so this bringsAttachVolumeto parity.The validation order is:
migration_status == "migrating"? → rejectRelease note: