Re: [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
From: Stephen Hemminger <stephen@networkplumber.org>
Date: 2016-06-17 19:04:19
On Fri, 17 Jun 2016 11:04:54 -0700 Anuradha Karuppiah [off-list ref] wrote:
On Tue, May 31, 2016 at 12:22 PM, Anuradha Karuppiah [off-list ref] wrote:quoted
On Tue, May 31, 2016 at 11:59 AM, Stephen Hemminger [off-list ref] wrote:quoted
On Fri, 27 May 2016 21:37:14 -0700 Roopa Prabhu [off-list ref] wrote:quoted
Sample output: $bridge -j fdb show [{ "mac": "44:38:39:00:69:88", "dev": "swp2s0", "vlan": 2, "master": "br0", "state": "permanent" },{ "mac": "00:02:00:00:00:01", "dev": "swp2s0", "vlan": 2, "master": "br0" },{ "mac": "00:02:00:00:00:02", "dev": "swp2s1", "vlan": 2, "master": "br0" },{ "mac": "44:38:39:00:69:89", "dev": "swp2s1", "master": "br0", "state": "permanent" },{ "mac": "44:38:39:00:69:89", "dev": "swp2s1", "vlan": 2, "master": "br0", "state": "permanent" },{ "mac": "44:38:39:00:69:88", "dev": "br0", "master": "br0", "state": "permanent" } ]In most JSON I have seen, the output would be: { "fdb" : [ { "mac": "44:38:39:00:69:88", "dev": "swp2s0", "vlan": 2, "master": "br0", "state": "permanent" }, ... ] } I.e never a bare array.Yes Stephen, Adding an extra level would be one way to force the format to json-object. And that would definitely be the way to do it if we ever added a top level json dump - something like - "bridge -j show". But in the case of "bridge -j fdb show" that level is redundant. To be consistent we would have to add that extra level to all json dumps (even if they were already objects; such as the "bridge -j vlan show").The google json style guide recommends against adding hierarchy unless needed. And it is not that uncommon in java to have a json-array of objects for e.g. http://json-schema.org/example1.html talks about a schema that is an "array of products". What do you recommend?Hi Stephen, We did a bit more digging around and found that other folks use json output with top level array as well. Here’s a docker networks json output sample - vagrant@host-21 ~ $ docker network inspect red [ { "Name": "red", "Id": "d2fff9bafd7564c4012aa49f322fcd8f5743cc5ceb465dc218af5ba22c920981", "Scope": "global", "Driver": "overlay", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "10.252.20.0/24" } ] }, "Internal": false, "Containers": { "c92084c1ebfb4f0a601537298c273078862207e3b564787ddd6ef564efbaca47": { "Name": "ctr21", "EndpointID": "e7468a70f13f1ea7b15445ab555374892ac41f71ea9023af1d9ede668bfd8742", "MacAddress": "02:42:0a:fc:14:03", "IPv4Address": "10.252.20.3/24", "IPv6Address": "" }, "ep-9bfc004b4046512f0f0104fe022d3686f5237ae08475741f8d520552cbb63d45": { "Name": "ctr22", "EndpointID": "9bfc004b4046512f0f0104fe022d3686f5237ae08475741f8d520552cbb63d45", "MacAddress": "02:42:0a:fc:14:02", "IPv4Address": "10.252.20.2/24", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] Adding an additional namespace to all the json outputs (just to avoid a top-level json-array for some) seems redundant. If a namespace is needed for other reasons we can definitely add it. So we think it would be better to just go with the top-level json-array for a list/set-of-objects outputs.
Ok, resubmit. I never claimed to be a JSON expert :=)