On 11/7/25 3:01 PM, Ilya Maximets wrote:
> On 11/6/25 12:00 PM, Corentin ARNOULD via discuss wrote:
>> Hello,
>
> Hi.
>
>>
>>
>> I figured the JSON output format is not exactly how I expected it to be.
>> Most of the data is represented using arrays, with headers being a
>> dictionary of all the column names, looking like a CSV with JSON format.
>> I provided an output for a newly created bridge for reference bellow.
>>
>> I looked a bit into the code, and it seems like there is an internal
>> representation of the data in json, and passing "-f json" just print the
>> internal representation. Which is not really readable by humans (or
>> "jq")...
>
> It should be a valid JSON. So, while it's not that easy to read, tools
> like jq should be able to work with it. Though, yes, it's not really
> straightforward.
>
>> I wrote a patch that modify the json format for output, but I
>> was wondering it was a good idea to change the json format directly or
>> if it was better to use an alternative name (like json2 or something),
>> as it would break backward compatibility if users used this feature in
>> scripts.
>>
>> When working on that, I found something interesting in the way arrays
>> are represented. Depending on the size, an array with the cardinality of
>> 1 would not be displayed as a set, but with 0 or 2 elements it would be
>> represented as a set:
>>
>> With 0 element: ["set", []]
>>
>> With 1 element: 0
>>
>> With 2 elements: ["set", [0, 1]]
>>
>> I tried patching this too, but it breaks a lot of tests (because it
>> changes the output format) and I was thinking that maybe this is an
>> intended feature.
>>
>>
>> So here are two questions:
>>
>> - Is a patch regarding json readability welcome ? If yes, should the
>> "json" format be modified or a new one being created ?
>>
>> - Is it expected to have a different representation of array with
>> cardinality 1 ?
>
> The JSON output format today is tied to the internal representation of
> the data inside the database. Everything in a database is a set and
> it represents 1-element sets as single values to avoid extra clutter
> for columns with scalar types. Empty sets can't be represented this way,
> so they are reported as empty sets. So, this is expected.
>
> I think, changing the format as it appears on a wire or in the database
> file is not an option for compatibility reasons, but we can make control
> utilities like ovs-vsctl print out the data prettier, if there is a desire
> for that. A separate format option might be a better choice for it, again,
> for compatibility reasons. We may call it 'json-compact' or something
> like this. We may also omit empty sets and arrays from the output to
> reduce the visual clutter even further.
>
> Best regards, Ilya Maximets.
>
>>
>>
>> I would love to help, but just trying to make it right.
>>
>> Have a good day,
>>
>> Regards,
>>
>> ---
>>
>> Current representation: "ovs-vsctl -f json list bridge | jq"
>>
>> {
>> "data": [
>> [
>> [
>> "uuid",
>> "59e32bd7-19b9-4532-b6dd-3b0ab50d2823"
>> ],
>> [
>> "set",
>> []
>> ],
>> [
>> "set",
>> []
>> ],
>> [
>> "set",
>> [
>> "0000d62be3593245"
>> ]
>> ],
>> "",
>> "<built-in>",
>> [
>> "map",
>> []
>> ],
>> [
>> "set",
>> []
>> ],
>> [
>> "set",
>> []
>> ],
>> [
>> "map",
>> []
>> ],
>> [
>> "set",
>> []
>> ],
>> false,
>> [
>> "set",
>> []
>> ],
>> "br0",
>> [
>> "set",
>> []
>> ],
>> [
>> "map",
>> []
>> ],
>> [
>> "set",
>> [
>> [
>> "uuid",
>> "4d6002d5-9451-4b19-95a7-34ac5b07b1e8"
>> ]
>> ]
>> ],
>> [
>> "set",
>> []
>> ],
>> false,
>> [
>> "map",
>> []
>> ],
>> [
>> "set",
>> []
>> ],
>> [
>> "map",
>> []
>> ],
>> false
>> ]
>> ],
>> "headings": [
>> "_uuid",
>> "auto_attach",
>> "controller",
>> "datapath_id",
>> "datapath_type",
>> "datapath_version",
>> "external_ids",
>> "fail_mode",
>> "flood_vlans",
>> "flow_tables",
>> "ipfix",
>> "mcast_snooping_enable",
>> "mirrors",
>> "name",
>> "netflow",
>> "other_config",
>> "ports",
>> "protocols",
>> "rstp_enable",
>> "rstp_status",
>> "sflow",
>> "status",
>> "stp_enable"
>> ]
>> }
>>
>> ---
>>
>> Proposed JSON representation: "ovs-vsctl -f json list bridge | jq"
>>
>> {
>> "data": [
>> {
>> "_uuid": "7b0b6a72-7f53-4789-94d3-5046adc554b2",
This formatting is also not particularly clean. There is no need in
wrapping everything in the "data" array. We should also probably
represent the table as a set of rows, where uuid is a key and the
set of the rest of the columns make up the value, e.g.:
{
"7b0b6a72-7f53-4789-94d3-5046adc554b2": {
"datapath_id": "0000726a0b7b8947",
"datapath_version": "<built-in>",
"mcast_snooping_enable": false,
"name": "br0",
"ports": ["655fb0d8-926a-43ea-9fa1-9106f7be7e8d"],
"rstp_enable": false,
"stp_enable": false
}
}
>> "auto_attach": [],
>> "controller": [],
>> "datapath_id": "0000726a0b7b8947",
>> "datapath_type": "",
>> "datapath_version": "<built-in>",
>> "external_ids": {},
>> "fail_mode": [],
>> "flood_vlans": [],
>> "flow_tables": {},
>> "ipfix": [],
>> "mcast_snooping_enable": false,
>> "mirrors": [],
>> "name": "br0",
>> "netflow": [],
>> "other_config": {},
>> "ports": "655fb0d8-926a-43ea-9fa1-9106f7be7e8d",
>> "protocols": [],
>> "rstp_enable": false,
>> "rstp_status": {},
>> "sflow": [],
>> "status": {},
>> "stp_enable": false
>> }
>> ]
>> }
>>
>
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
