[release-2.11] fix(pure): Make Pure FlashArray HTTP client timeout configurable

[github-actions]

Backport: #5551

Make Pure FlashArray HTTP client timeout configurable

Problem:

During migrations of VMs with many disks, simultaneous CopyVolume requests to Pure FlashArray were timing out, leaving PVCs stuck in Pending. In one observed case, 15 disks were migrated but only 7 reached Bound status — the remaining 8 populator pods failed with:

failed to copy VMDK using VVol storage API: copy operation failed: Pure FlashArray CopyVolume failed:
failed to send copy volume request: Post "https://<array>/api/2.46/volumes?overwrite=true":
context deadline exceeded (Client.Timeout exceeded while awaiting headers)

The root cause is that the HTTP client timeout was hardcoded to 30 seconds with no way to extend it, making it impossible to accommodate slower or heavily-loaded arrays.

Changes:

• NewRestClient now accepts an httpTimeoutSeconds int parameter instead of a hardcoded value. A value of <= 0 falls back to the 30s default.
• NewFlashArrayClonner threads the parameter through to NewRestClient.
• A --storage-api-timeout-seconds CLI flag (default: 30) is added to the vsphere-xcopy-volume-populator binary.

How to configure:

Pass --storage-api-timeout-seconds=<value> to the populator binary. Full operator-side wiring (CRD field → VSphereXcopyPluginConfig → VSphereXcopyVolumePopulatorSpec → populator-controller pod args) is a follow-up.

Default behaviour is unchanged — the timeout remains 30 seconds unless explicitly overridden.

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE