[cinder-csi-plugin] Wait for volume availability before attach

[hemna]

What this PR does / why we need it:

ControllerPublishVolume now waits for the volume to reach available or in-use status before calling the Cinder attachment API.

Previously, if the CO called ControllerPublishVolume immediately after CreateVolume, the volume could still be in creating state on the backend. This caused Cinder to reject the attachment with a 409 Conflict:

Volume X status must be available or downloading to reserve, but the current status is creating.

This forced the CO (external-attacher) to retry blindly, generating unnecessary API calls to Cinder and delaying volume attachment. The issue is most pronounced with storage backends where volume creation is asynchronous and takes several seconds (e.g., when volumes are backed by network-attached storage).

How the fix works:

A new WaitVolumeTargetStatusWithContext method uses wait.PollUntilContextCancel which:

1. Polls the volume status every 3 seconds
2. Returns immediately if the volume is already available or in-use
3. Returns an error if the volume enters an error state
4. Respects the gRPC context deadline (no fixed step count — bounded by the CO's RPC timeout)

If the context expires before the volume is ready, the driver returns FAILED_PRECONDITION which tells the CO to retry with exponential backoff.

Which issue this PR fixes(if applicable):
fixes #

Special notes for reviewers:

The volumeReadyPollInterval is set to 3 seconds, which balances responsiveness against API load on the Cinder service. The total wait time is bounded by the gRPC context deadline (typically 15-30s depending on the external-attacher configuration), not a fixed backoff.

The existing WaitVolumeTargetStatus (used in ControllerExpandVolume) is left unchanged to avoid disrupting existing behavior.

Release note:

[cinder-csi-plugin] ControllerPublishVolume now waits for volumes to become available before calling the Cinder attach API, eliminating 409 Conflict errors when volumes are still being provisioned.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign zetaab for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions 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.