Hi Ilya, thanks a lot for the review!
> I wonder if what you actually want is to show the fdb tables of
> all the bridges? Or most of the bridges? We have many different
> commands for which the standard behavior is to print information
> for all bridges/datapaths/ports in case a specific target is not
> specified, i.e. the call has no arguemnts. So, I wonder if it
> would be better to instead of supporting multiple arguments with
> support the case of no arguments and show information for all
> bridges in this case, as that would be more in line with other
> commands we have.
On the argument handling, I'd like to support two cases
1. No args -> show all bridges. I agree this is the right default and
matches our other commands.
2. One or more args -> show just those bridges.
The reason for keeping case 2 is that agents often poll only a subset
of bridges (e.g. an EVPN agent only cares about its own VNIs).
Always dumping every bridge would walk FDB tables the client doesn't
need. Does that sound reasonable?
> Some more comments below.
I agreed with all the other comments:)
1. On the text args: I'll turn the bridge name into a column instead,
with two variants of the table.
2. On the JSON output: "bridge"/"entries" isn't a great shape. I'll
key the object by bridge name with the entries array as the value,
i.e. {"br0": [...], "br1": [...]}. Entries stay an array since there's
no unique key for them.
I'll also trim the NEWS entry down to the first line and switch to two
blank lines between sections for the major release.
Thanks again,
Takeru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
