Pure Storage driver fails to create volume from snapshot with py-pure-client

[kubilaykaptanoglu]

[Cinder] Pure Storage driver fails to create volume from snapshot with py-pure-client

Summary

When using the Pure Storage Cinder driver with OpenStack 2025.1, creating a volume from a snapshot fails with a Pydantic validation error when py-pure-client

The issue was reproduced with:

• OpenStack Cinder: 26.2.1

• OpenStack release: 2025.1

• py-pure-client: 1.93.0 — fails

• py-pure-client: 1.89.0 — fails

• py-pure-client: 1.85.0 — works

• Python: 3.12

• Pydantic: 2.13.4

• Pure Storage REST client: purestorage==1.19.0

Description

When creating a volume from a snapshot backed by Pure Storage, the Cinder Pure driver calls flasharray.VolumePatch() in cinder/volume/drivers/pure.py.

The operation fails before the request is sent to the Pure Storage API because the VolumePatch Pydantic model rejects the QoS fields:

pydantic.v1.error_wrappers.ValidationError: 2 validation errors for VolumePatch
qos -> bandwidth_limit

value is not a valid dict (type=type_error.dict)
qos -> iops_limit

value is not a valid dict (type=type_error.dict)

The relevant Cinder call path is:

cinder.volume.flows.manager.create_volume

-> _create_from_snapshot()

-> driver.create_volume_from_snapshot()

-> cinder.volume.drivers.pure.py

-> flasharray.VolumePatch()

-> Pydantic ValidationError

The failure occurs at approximately:

cinder/volume/drivers/pure.py:834

The error is triggered while executing:

flasharray.VolumePatch(...)

The failure causes the volume creation task to revert:

Flow 'volume_create_manager' transitioned to state 'REVERTED'

A subsequent cleanup attempt also reports:

Volume deletion failed with message: Volume does not exist.

Reproduction

1. Configure OpenStack Cinder with the Pure Storage backend.

2. Create a volume.

3. Create a snapshot from the volume.

4. Attempt to create a new volume from the snapshot.

5. The operation fails with:

ValidationError: 2 validation errors for VolumePatch

qos -> bandwidth_limit

value is not a valid dict

qos -> iops_limit

value is not a valid dict

Version comparison

py-pure-client version	Result
1.85.0	Works
1.89.0	Fails
1.93.0	Fails

The runtime package was changed to py-pure-client==1.85.0 in the Cinder volume container, followed by a cinder_volume service restart. After this change, creating a volume from a snapshot completed successfully.

Expected behavior

Creating a volume from a Pure Storage-backed snapshot should complete successfully with supported versions of py-pure-client.

The Cinder Pure driver and the py-pure-client version should use compatible QoS models for VolumePatch.

Actual behavior

The Pure Storage Cinder driver passes QoS values to flasharray.VolumePatch(), but py-pure-client rejects bandwidth_limit and iops_limit because the received values are not in the expected dictionary format.

The failure occurs during local Pydantic model validation, before communication with the Pure Storage FlashArray API.

Workaround

Downgrading py-pure-client to:

py-pure-client==1.85.0

resolves the issue.

This workaround was verified in the Cinder volume container by replacing py-pure-client==1.93.0 with py-pure-client==1.85.0 and restarting the cinder_volume service.

Request

Please investigate the compatibility between the OpenStack 2025.1 Cinder Pure Storage driver and py-pure-client versions 1.89.0+.

It appears that a change in the VolumePatch/QoS model between py-pure-client versions may be incompatible with the current Cinder Pure driver implementation.

A permanent fix could be either:

1. Updating the Cinder Pure driver to use the new QoS model expected by newer py-pure-client versions, or

2. Pinning the compatible py-pure-client version for the affected OpenStack release.

[sdodsley]

We are aware of this issue and the latest Red Hat OpenStack container correctly pins this version.
A patch has already been created for the upstream driver (994947: [Everpure] Fix QoS for py-pure-client 1.86.0+ | https://review.opendev.org/c/openstack/cinder/+/994947) and there are backports to older versions in progress.

[kubilaykaptanoglu]

Unfortunately, this patch seems to be limited to the master branch and hasn't been merged for versions 2026.1 and 2025.1. We'll need to create a custom solution by manually fixing it.Thank you for your feedback.

[sdodsley]

Backports will continue in the prescribed process. Further backports are pending