* [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
@ 2016-05-28 4:37 Roopa Prabhu
2016-05-31 18:59 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Roopa Prabhu @ 2016-05-28 4:37 UTC (permalink / raw)
To: stephen, netdev; +Cc: anuradhak, nikolay, julien
From: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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"
}
]
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
bridge/fdb.c | 204 +++++++++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 162 insertions(+), 42 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index be849f9..79e9cbb 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -21,6 +21,8 @@
#include <linux/neighbour.h>
#include <string.h>
#include <limits.h>
+#include <json_writer.h>
+#include <stdbool.h>
#include "libnetlink.h"
#include "br_common.h"
@@ -29,6 +31,8 @@
static unsigned int filter_index, filter_vlan;
+json_writer_t *jw_global;
+
static void usage(void)
{
fprintf(stderr, "Usage: bridge fdb { add | append | del | replace } ADDR dev DEV\n"
@@ -59,6 +63,15 @@ static const char *state_n2a(unsigned int s)
return buf;
}
+static void start_json_fdb_flags_array(bool *fdb_flags)
+{
+ if (*fdb_flags)
+ return;
+ jsonw_name(jw_global, "flags");
+ jsonw_start_array(jw_global);
+ *fdb_flags = true;
+}
+
int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
{
FILE *fp = arg;
@@ -66,11 +79,12 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
int len = n->nlmsg_len;
struct rtattr *tb[NDA_MAX+1];
__u16 vid = 0;
+ bool fdb_flags = false;
+ const char *state_s;
if (n->nlmsg_type != RTM_NEWNEIGH && n->nlmsg_type != RTM_DELNEIGH) {
fprintf(stderr, "Not RTM_NEWNEIGH: %08x %08x %08x\n",
n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
-
return 0;
}
@@ -86,6 +100,11 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
if (filter_index && filter_index != r->ndm_ifindex)
return 0;
+ if (jw_global) {
+ jsonw_pretty(jw_global, 1);
+ jsonw_start_object(jw_global);
+ }
+
parse_rtattr(tb, NDA_MAX, NDA_RTA(r),
n->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
@@ -96,39 +115,73 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
return 0;
if (n->nlmsg_type == RTM_DELNEIGH)
- fprintf(fp, "Deleted ");
+ if (jw_global)
+ jsonw_string_field(jw_global, "opCode", "deleted");
+ else
+ fprintf(fp, "Deleted ");
if (tb[NDA_LLADDR]) {
SPRINT_BUF(b1);
- fprintf(fp, "%s ",
- ll_addr_n2a(RTA_DATA(tb[NDA_LLADDR]),
- RTA_PAYLOAD(tb[NDA_LLADDR]),
- ll_index_to_type(r->ndm_ifindex),
- b1, sizeof(b1)));
+ ll_addr_n2a(RTA_DATA(tb[NDA_LLADDR]),
+ RTA_PAYLOAD(tb[NDA_LLADDR]),
+ ll_index_to_type(r->ndm_ifindex),
+ b1, sizeof(b1));
+ if (jw_global)
+ jsonw_string_field(jw_global, "mac", b1);
+ else
+ fprintf(fp, "%s ", b1);
}
- if (!filter_index && r->ndm_ifindex)
- fprintf(fp, "dev %s ", ll_index_to_name(r->ndm_ifindex));
+ if (!filter_index && r->ndm_ifindex) {
+ if (jw_global)
+ jsonw_string_field(jw_global, "dev",
+ ll_index_to_name(r->ndm_ifindex));
+ else
+ fprintf(fp, "dev %s ",
+ ll_index_to_name(r->ndm_ifindex));
+ }
if (tb[NDA_DST]) {
int family = AF_INET;
+ const char *abuf_s;
if (RTA_PAYLOAD(tb[NDA_DST]) == sizeof(struct in6_addr))
family = AF_INET6;
- fprintf(fp, "dst %s ",
- format_host(family,
- RTA_PAYLOAD(tb[NDA_DST]),
- RTA_DATA(tb[NDA_DST])));
+ abuf_s = format_host(family,
+ RTA_PAYLOAD(tb[NDA_DST]),
+ RTA_DATA(tb[NDA_DST]));
+ if (jw_global)
+ jsonw_string_field(jw_global, "dst", abuf_s);
+ else
+ fprintf(fp, "dst %s ", abuf_s);
}
- if (vid)
- fprintf(fp, "vlan %hu ", vid);
+ if (vid) {
+ if (jw_global)
+ jsonw_uint_field(jw_global, "vlan", vid);
+ else
+ fprintf(fp, "vlan %hu ", vid);
+ }
+
+ if (tb[NDA_PORT]) {
+ if (jw_global)
+ jsonw_uint_field(jw_global, "port",
+ ntohs(rta_getattr_u16(tb[NDA_PORT])));
+ else
+ fprintf(fp, "port %d ",
+ ntohs(rta_getattr_u16(tb[NDA_PORT])));
+ }
+
+ if (tb[NDA_VNI]) {
+ if (jw_global)
+ jsonw_uint_field(jw_global, "vni",
+ rta_getattr_u32(tb[NDA_VNI]));
+ else
+ fprintf(fp, "vni %d ",
+ rta_getattr_u32(tb[NDA_VNI]));
+ }
- if (tb[NDA_PORT])
- fprintf(fp, "port %d ", ntohs(rta_getattr_u16(tb[NDA_PORT])));
- if (tb[NDA_VNI])
- fprintf(fp, "vni %d ", rta_getattr_u32(tb[NDA_VNI]));
if (tb[NDA_IFINDEX]) {
unsigned int ifindex = rta_getattr_u32(tb[NDA_IFINDEX]);
@@ -136,37 +189,95 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
char ifname[IF_NAMESIZE];
if (!tb[NDA_LINK_NETNSID] &&
- if_indextoname(ifindex, ifname))
- fprintf(fp, "via %s ", ifname);
- else
- fprintf(fp, "via ifindex %u ", ifindex);
+ if_indextoname(ifindex, ifname)) {
+ if (jw_global)
+ jsonw_string_field(jw_global, "viaIf",
+ ifname);
+ else
+ fprintf(fp, "via %s ", ifname);
+ } else {
+ if (jw_global)
+ jsonw_uint_field(jw_global, "viaIfIndex",
+ ifindex);
+ else
+ fprintf(fp, "via ifindex %u ", ifindex);
+ }
}
}
- if (tb[NDA_LINK_NETNSID])
- fprintf(fp, "link-netnsid %d ",
- rta_getattr_u32(tb[NDA_LINK_NETNSID]));
+
+ if (tb[NDA_LINK_NETNSID]) {
+ if (jw_global)
+ jsonw_uint_field(jw_global, "linkNetNsId",
+ rta_getattr_u32(tb[NDA_LINK_NETNSID]));
+ else
+ fprintf(fp, "link-netnsid %d ",
+ rta_getattr_u32(tb[NDA_LINK_NETNSID]));
+ }
if (show_stats && tb[NDA_CACHEINFO]) {
struct nda_cacheinfo *ci = RTA_DATA(tb[NDA_CACHEINFO]);
int hz = get_user_hz();
- fprintf(fp, "used %d/%d ", ci->ndm_used/hz,
- ci->ndm_updated/hz);
+ if (jw_global) {
+ jsonw_uint_field(jw_global, "used",
+ ci->ndm_used/hz);
+ jsonw_uint_field(jw_global, "updated",
+ ci->ndm_updated/hz);
+ } else {
+ fprintf(fp, "used %d/%d ", ci->ndm_used/hz,
+ ci->ndm_updated/hz);
+ }
+ }
+
+ if (jw_global) {
+ if (r->ndm_flags & NTF_SELF) {
+ start_json_fdb_flags_array(&fdb_flags);
+ jsonw_string(jw_global, "self");
+ }
+ if (r->ndm_flags & NTF_ROUTER) {
+ start_json_fdb_flags_array(&fdb_flags);
+ jsonw_string(jw_global, "router");
+ }
+ if (r->ndm_flags & NTF_EXT_LEARNED) {
+ start_json_fdb_flags_array(&fdb_flags);
+ jsonw_string(jw_global, "offload");
+ }
+ if (r->ndm_flags & NTF_MASTER)
+ jsonw_string(jw_global, "master");
+ if (fdb_flags)
+ jsonw_end_array(jw_global);
+
+ if (tb[NDA_MASTER])
+ jsonw_string_field(jw_global,
+ "master",
+ ll_index_to_name(rta_getattr_u32(tb[NDA_MASTER])));
+
+ } else {
+ if (r->ndm_flags & NTF_SELF)
+ fprintf(fp, "self ");
+ if (r->ndm_flags & NTF_ROUTER)
+ fprintf(fp, "router ");
+ if (r->ndm_flags & NTF_EXT_LEARNED)
+ fprintf(fp, "offload ");
+ if (tb[NDA_MASTER]) {
+ fprintf(fp, "master %s ",
+ ll_index_to_name(rta_getattr_u32(tb[NDA_MASTER])));
+ } else if (r->ndm_flags & NTF_MASTER) {
+ fprintf(fp, "master ");
+ }
+ }
+
+ state_s = state_n2a(r->ndm_state);
+ if (jw_global) {
+ if (state_s[0])
+ jsonw_string_field(jw_global, "state", state_s);
+
+ jsonw_end_object(jw_global);
+ } else {
+ fprintf(fp, "%s\n", state_s);
+
+ fflush(fp);
}
- if (r->ndm_flags & NTF_SELF)
- fprintf(fp, "self ");
- if (tb[NDA_MASTER])
- fprintf(fp, "master %s ",
- ll_index_to_name(rta_getattr_u32(tb[NDA_MASTER])));
- else if (r->ndm_flags & NTF_MASTER)
- fprintf(fp, "master ");
- if (r->ndm_flags & NTF_ROUTER)
- fprintf(fp, "router ");
- if (r->ndm_flags & NTF_EXT_LEARNED)
- fprintf(fp, "offload ");
-
- fprintf(fp, "%s\n", state_n2a(r->ndm_state));
- fflush(fp);
return 0;
}
@@ -233,10 +344,19 @@ static int fdb_show(int argc, char **argv)
exit(1);
}
+ if (json_output) {
+ jw_global = jsonw_new_array(stdout);
+ if (!jw_global) {
+ fprintf(stderr, "Error allocation json object\n");
+ exit(1);
+ }
+ }
if (rtnl_dump_filter(&rth, print_fdb, stdout) < 0) {
fprintf(stderr, "Dump terminated\n");
exit(1);
}
+ if (jw_global)
+ jsonw_destroy(&jw_global);
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
2016-05-28 4:37 [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show Roopa Prabhu
@ 2016-05-31 18:59 ` Stephen Hemminger
2016-05-31 19:22 ` Anuradha Karuppiah
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2016-05-31 18:59 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev, anuradhak, nikolay, julien
On Fri, 27 May 2016 21:37:14 -0700
Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
2016-05-31 18:59 ` Stephen Hemminger
@ 2016-05-31 19:22 ` Anuradha Karuppiah
2016-06-17 18:04 ` Anuradha Karuppiah
0 siblings, 1 reply; 6+ messages in thread
From: Anuradha Karuppiah @ 2016-05-31 19:22 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Roopa Prabhu, netdev@vger.kernel.org, Nikolay Aleksandrov, julien
On Tue, May 31, 2016 at 11:59 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Fri, 27 May 2016 21:37:14 -0700
> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>
>> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
2016-05-31 19:22 ` Anuradha Karuppiah
@ 2016-06-17 18:04 ` Anuradha Karuppiah
2016-06-17 19:04 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Anuradha Karuppiah @ 2016-06-17 18:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Roopa Prabhu, netdev@vger.kernel.org, Nikolay Aleksandrov,
Julien Fortin
On Tue, May 31, 2016 at 12:22 PM, Anuradha Karuppiah
<anuradhak@cumulusnetworks.com> wrote:
> On Tue, May 31, 2016 at 11:59 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
>> On Fri, 27 May 2016 21:37:14 -0700
>> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>>
>>> 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.
thanks
Anuradha.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
2016-06-17 18:04 ` Anuradha Karuppiah
@ 2016-06-17 19:04 ` Stephen Hemminger
2016-06-17 19:07 ` Anuradha Karuppiah
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2016-06-17 19:04 UTC (permalink / raw)
To: Anuradha Karuppiah
Cc: Roopa Prabhu, netdev@vger.kernel.org, Nikolay Aleksandrov,
Julien Fortin
On Fri, 17 Jun 2016 11:04:54 -0700
Anuradha Karuppiah <anuradhak@cumulusnetworks.com> wrote:
> On Tue, May 31, 2016 at 12:22 PM, Anuradha Karuppiah
> <anuradhak@cumulusnetworks.com> wrote:
> > On Tue, May 31, 2016 at 11:59 AM, Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> >> On Fri, 27 May 2016 21:37:14 -0700
> >> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> >>
> >>> 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 :=)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show
2016-06-17 19:04 ` Stephen Hemminger
@ 2016-06-17 19:07 ` Anuradha Karuppiah
0 siblings, 0 replies; 6+ messages in thread
From: Anuradha Karuppiah @ 2016-06-17 19:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Roopa Prabhu, netdev@vger.kernel.org, Nikolay Aleksandrov,
Julien Fortin
On Fri, Jun 17, 2016 at 12:04 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Fri, 17 Jun 2016 11:04:54 -0700
> Anuradha Karuppiah <anuradhak@cumulusnetworks.com> wrote:
>
>> On Tue, May 31, 2016 at 12:22 PM, Anuradha Karuppiah
>> <anuradhak@cumulusnetworks.com> wrote:
>> > On Tue, May 31, 2016 at 11:59 AM, Stephen Hemminger
>> > <stephen@networkplumber.org> wrote:
>> >> On Fri, 27 May 2016 21:37:14 -0700
>> >> Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>> >>
>> >>> 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 :=)
will do :)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-06-17 19:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-28 4:37 [PATCH iproute2 net-next 3/5] bridge: add json support for bridge fdb show Roopa Prabhu
2016-05-31 18:59 ` Stephen Hemminger
2016-05-31 19:22 ` Anuradha Karuppiah
2016-06-17 18:04 ` Anuradha Karuppiah
2016-06-17 19:04 ` Stephen Hemminger
2016-06-17 19:07 ` Anuradha Karuppiah
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).