Type inconsistency when CLI output in JSON format

[michael-mcaleer]

OpenStack volume attributes are stored as 0/1 in the Cinder DB, PowerMax True/False bools are stored as boolean values, so everything is fine from a Cinder perspective and how these values are persisted in the CInder DB.

mysql> select id, display_name, bootable, multiattach from volumes;
+--------------------------------------+--------------------------------------------+----------+-------------+
| id | display_name | bootable | multiattach |
+--------------------------------------+--------------------------------------------+----------+-------------+
| 931d3c54-da00-4640-9ab8-23bd475f512d | image-2b44e9e3-06b3-4dbd-bb82-e5988c51b3a0 | 0 | 0 |
| d274a95b-64e2-4821-90d3-00e2b3f98302 | test | 1 | 0 |
| e271f430-e2cc-46ec-be37-17676b4ce6d3 | t1 | 0 | 0 |
| e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | boot_test | 1 | 0 |
+--------------------------------------+--------------------------------------------+----------+-------------+

mysql> select * from volume_metadata where volume_id='e45f8a47-71df-49a6-95b0-ac4dfa45bf91';
+---------------------+------------+------------+---------+----+--------------------------------------+---------------------+-----------------------------------------+
| created_at | updated_at | deleted_at | deleted | id | volume_id | key | value |
+---------------------+------------+------------+---------+----+--------------------------------------+---------------------+-----------------------------------------+
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 21 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | DeviceID | 00D77 |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 22 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | DeviceLabel | OS-e45f8a47-71df-49a6-95b0-ac4dfa45bf91 |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 23 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | ArrayID | 000297900330 |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 24 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | ArrayModel | PowerMax_2000 |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 25 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | ServiceLevel | None |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 26 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | Workload | None |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 27 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | Emulation | FBA |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 28 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | Configuration | TDEV |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 29 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | CompressionDisabled | True |
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 30 | e45f8a47-71df-49a6-95b0-ac4dfa45bf91 | ReplicationEnabled | False |
+---------------------+------------+------------+---------+----+--------------------------------------+---------------------+-----------------------------------------+

When the usual Cinder client is used and not the openstack volume client everything is also as intended in the pretty-table representation.

When we go to the openstack volume client and format the CLI output as JSON there is an inconsistency with key value types. For example, 'bootable' is a string representation of 'false', whilst 'encrypted' and 'multiattach' are boolean type values. Looking at the PowerMax device metadata values, 'True/False' values are output as strings regardless of how they are persisted in the Cinder DB.

stack@test-host:~/devstack$ openstack volume show t3 -f json
{
"attachments": [],
"availability_zone": "nova",
"bootable": "false", <<<<<<<<<< This is a string
"consistencygroup_id": null,
"created_at": "2020-06-09T14:13:26.000000",
"description": "",
"encrypted": false, <<<<<<<<<< This is a boolean
"id": "3cfba202-c2dd-4c73-b345-f8f93031e2c0",
"migration_status": null,
"multiattach": false, <<<<<<<<<< This is a boolean
"name": "t3",
"os-vol-host-attr:host": "test-host@POWERMAX_ISCSI_NONE#None+None+SRP_1+000297900330",
"os-vol-mig-status-attr:migstat": null,
"os-vol-mig-status-attr:name_id": null,
"os-vol-tenant-attr:tenant_id": "498714e5a42b4541be03f56146ed27a1",
"properties": {
"DeviceID": "00E95",
"DeviceLabel": "OS-3cfba202-c2dd-4c73-b345-f8f93031e2c0",
"ArrayID": "000111222333",
"ArrayModel": "PowerMax_2000",
"ServiceLevel": "None",
"Workload": "None",
"Emulation": "FBA",
"Configuration": "TDEV",
"CompressionDisabled": "True", <<<<<<<<<< This is a string
"TempTest": "True", <<<<<<<<<< This is a string
"ReplicationEnabled": "False" <<<<<<<<<< This is a string
},
"replication_status": null,
"size": 1,
"snapshot_id": null,
"source_volid": null,
"status": "available",
"type": "POWERMAX_ISCSI_NONE",
"updated_at": "2020-06-09T14:13:57.000000",
"user_id": "cd44eb70defc454f8cda49cf20d060d2"
}

The end goal here would be to have consistent JSON key/value types to take the onus off the end user to process JSON values and change types were necessary.

[Balint Harmath (bharmath)]

Nice writing down of the problem. The suggestion for the correct state is provided. For users it is unavoidable.