Type inconsistency when CLI output in JSON format
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
python-openstackclient (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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-
| d274a95b-
| e271f430-
| e45f8a47-
+------
mysql> select * from volume_metadata where volume_
+------
| created_at | updated_at | deleted_at | deleted | id | volume_id | key | value |
+------
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 21 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 22 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 23 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 24 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 25 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 26 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 27 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 28 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 29 | e45f8a47-
| 2020-06-02 11:10:07 | NULL | NULL | 0 | 30 | e45f8a47-
+------
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-
{
"attachments": [],
"availability_
"bootable": "false", <<<<<<<<<< This is a string
"consistencygro
"created_at": "2020-06-
"description": "",
"encrypted": false, <<<<<<<<<< This is a boolean
"id": "3cfba202-
"migration_status": null,
"multiattach": false, <<<<<<<<<< This is a boolean
"name": "t3",
"os-vol-
"os-vol-
"os-vol-
"os-vol-
"properties": {
"DeviceID": "00E95",
"DeviceLabel": "OS-3cfba202-
"ArrayID": "000111222333",
"ArrayModel": "PowerMax_2000",
"ServiceLevel": "None",
"Workload": "None",
"Emulation": "FBA",
"Configuration": "TDEV",
"CompressionDis
"TempTest": "True", <<<<<<<<<< This is a string
"ReplicationEna
},
"replication_
"size": 1,
"snapshot_id": null,
"source_volid": null,
"status": "available",
"type": "POWERMAX_
"updated_at": "2020-06-
"user_id": "cd44eb70defc45
}
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.
summary: |
- Type inconsistency when CLI output in JSON formatted + Type inconsistency when CLI output in JSON format |
Nice writing down of the problem. The suggestion for the correct state is provided. For users it is unavoidable.