solidfire-sdk-python icon indicating copy to clipboard operation
solidfire-sdk-python copied to clipboard

`list_active_volumes()` returns `VolumeAccess` class instead of str

Open scaleoutsean opened this issue 1 year ago • 1 comments

list_active_volumes returns VolumeAccess class in access value (the first KV). Isn't it supposed to return a str?

>>> sfe_a.list_active_volumes().to_json()['volumes'][0]
2024-06-07 14:37:28,267 - solidfire.Element - INFO - {"method": "ListActiveVolumes", "id": 54, "params": {}}
{'access': {}, 'accountID': 1, 'attributes': {}, 'blockSize': 4096, 'createTime': '2023-02-27T17:04:09Z', 'currentProtectionScheme': {}, 'deleteTime': '', 'enable512e': True, 'enableSnapMirrorReplication': False, 'fifoSize': 5, 'iqn': 'iqn.2010-01.com.solidfire:wcwb.data.1', 'lastAccessTime': '2024-03-30T15:49:50Z', 'lastAccessTimeIO': '2024-03-30T14:40:59Z', 'minFifoSize': 0, 'name': 'data', 'purgeTime': '', 'qos': {'burstIOPS': 3000, 'burstTime': 60, 'curve': {'1048576': 15000, '131072': 1950, '16384': 270, '262144': 3900, '32768': 500, '4096': 100, '524288': 7600, '65536': 1000, '8192': 160}, 'maxIOPS': 1500, 'minIOPS': 100}, 'qosPolicyID': 2, 'scsiEUIDeviceID': '7763776200000001f47acc0100000000', 'scsiNAADeviceID': '6f47acc1000000007763776200000001', 'sliceCount': 1, 'status': 'active', 'totalSize': 2000683008, 'volumeAccessGroups': [], 'volumeConsistencyGroupUUID': 'e6b28e75-c21c-4bad-8a2e-056bcec14e4c', 'volumeID': 1, 'volumePairs': [], 'volumeUUID': '4b31894c-b3d4-4dbc-a438-d60aa96f7c49'}


This works fine, so it appears there's something wrong in list_active_volumes.

>>> sfe_a.invoke_sfapi('ListActiveVolumes')['volumes'][0]
2024-06-07 14:37:58,731 - solidfire.Element - INFO - {"method": "ListActiveVolumes", "id": 55, "params": {}}
{'access': 'readWrite', 'accountID': 1, 'attributes': {}, 'blockSize': 4096, 'createTime': '2023-02-27T17:04:09Z', 'currentProtectionScheme': 'singleHelix', 'deleteTime': '', 'enable512e': True, 'enableSnapMirrorReplication': False, 'fifoSize': 5, 'iqn': 'iqn.2010-01.com.solidfire:wcwb.data.1', 'lastAccessTime': '2024-03-30T15:49:50Z', 'lastAccessTimeIO': '2024-03-30T14:40:59Z', 'minFifoSize': 0, 'name': 'data', 'previousProtectionScheme': None, 'purgeTime': '', 'qos': {'burstIOPS': 3000, 'burstTime': 60, 'curve': {'1048576': 15000, '131072': 1950, '16384': 270, '262144': 3900, '32768': 500, '4096': 100, '524288': 7600, '65536': 1000, '8192': 160}, 'maxIOPS': 1500, 'minIOPS': 100}, 'qosPolicyID': 2, 'scsiEUIDeviceID': '7763776200000001f47acc0100000000', 'scsiNAADeviceID': '6f47acc1000000007763776200000001', 'sliceCount': 1, 'status': 'active', 'totalSize': 2000683008, 'virtualVolumeID': None, 'volumeAccessGroups': [], 'volumeConsistencyGroupUUID': 'e6b28e75-c21c-4bad-8a2e-056bcec14e4c', 'volumeID': 1, 'volumePairs': [], 'volumeUUID': '4b31894c-b3d4-4dbc-a438-d60aa96f7c49'}

>>> sfe_a.api_version
12.5

$ python --version
Python 3.10.12
$ pip list | grep solidfire
solidfire-sdk-python                         12.3.0.203  

scaleoutsean avatar Jun 07 '24 06:06 scaleoutsean

The same bug in list_volumes_for_account.

>>> sfe.list_volumes_for_account(8).to_json()['volumes']
[{'access': {}, 'accountID': 8, ...]

scaleoutsean avatar Jul 11 '24 04:07 scaleoutsean

Thank you for raising this concern.

After reviewing the behavior, we’d like to clarify that this is not a bug. The difference you're observing stems from how the SDK handles deserialization:

  1. The invoke_sfapi() method is a generic API executor that simply deserializes the raw JSON response and returns it as-is. This is why fields like access appear as plain strings (e.g., 'readWrite').
  2. In contrast, methods like list_active_volumes() and list_volumes_for_account() use model-based deserialization, which maps fields to corresponding Python classes (e.g., VolumeAccess). This is the default behavior of Python object deserialization and applies consistently across all Element API methods in the SDK. So, the presence of class objects like VolumeAccess is expected and consistent with the SDK’s design. This behavior is not specific to these APIs, and therefore, no changes are planned.

Closing this ticket. Feel free to reopen it if you have any further questions or need clarification.

arjun960 avatar Sep 25 '25 21:09 arjun960