[j-nsp] certain commands executed on CLI provide additional information over corresponding RPCs
Saku Ytti
saku at ytti.fi
Fri Mar 9 08:14:33 EST 2018
Hey Martin,
I get what you're saying, but I think the problem is backwards. CLI is
opinionated, CLI mangles the backend data.
So you should rather complain why CLI isn't used the right words.
I understand what you're saying, but I don't agree it makes sense. It
would add work, as you still couldn't use what you said to stop
formatting it in CLI. So Juniper would need to add those CLI words to
RPC and still write the printf format in CLI. Only way I see this
being remotely sensible, is if RPC would return whole printf format
with %s, %x etc.
So that CLI developers actually don't write any formatting, and it's
all in RPC. If you'd want to replicate the CLI, you'd just take the
printf format and give it array of variables.
For me, I see zero value. But admit people do things differently, and
it might make sense.
On 9 March 2018 at 15:04, Martin T <m4rtntns at gmail.com> wrote:
> On Fri, Mar 9, 2018 at 2:25 PM, Saku Ytti <saku at ytti.fi> wrote:
>> Ah.
>>
>> Your point is that the strings are different? CLI says 'Rtr' tag says
>> 'isrouter'?
>>
>> I can't relate this being a problem, sorry. The data is there, you can
>> classify and reprint it as you wish.
>>
>> On 9 March 2018 at 12:37, Martin T <m4rtntns at gmail.com> wrote:
>>> On Thu, Mar 8, 2018 at 11:51 AM, Saku Ytti <saku at ytti.fi> wrote:
>>>> Hey Phil,
>>>>
>>>> I'm hijacking this for a bit.
>>>>
>>>> You have | display json and xml, I assume json was relatively modest
>>>> amount of work, as you have formal source of data, so someone only
>>>> needed to write translator, without being aware of all context to
>>>> support | display json, which also means, no one needs to do any work
>>>> to get display xml or json to work on new command introduced?
>>>>
>>>> If this is remotely true, shouldn't it be equally possibly to present
>>>> all data over SNMP which is presentable as JSON and XML? There are
>>>> bunch of gaps on relatively important stuff, which I'd love to see
>>>> available in SNMP. This week particularly I was frustrated to find how
>>>> 'show class-of-service fabric statistics' is not available over SNMP.
>>>> Perhaps introduce some CLI-MIB where all json/xml supporting commands
>>>> are generated in OIDs and command in CLI to ask OID for particular
>>>> command?
>>>>
>>>>
>>>>
>>>>
>>>> On 8 March 2018 at 07:26, Phil Shafer <phil at juniper.net> wrote:
>>>>> Martin T writes:
>>>>>>I have noticed that certain commands executed on CLI provide some
>>>>>>additional information over corresponding RPCs. For example "show ipv6
>>>>>>neighbors" or "show system storage" on CLI show column names while XML
>>>>>>output does not contain this data. Why is that so?
>>>>>
>>>>> Both the CLI and RPC content contain the same information, but the
>>>>> CLI takes the data supplied by the RPC and displays it using rules
>>>>> specified by the developer. These rules include column headers,
>>>>> field titles, and other gritty little details.
>>>>>
>>>>> But these are "display" features. The API is meant to allow access
>>>>> to the data, and to make that data the same data used by the CLI,
>>>>> so the API is complete, up-to-date, well-tested, and useful.
>>>>>
>>>>> If you want to use the API to get pure text data, we do have the
>>>>> 'format="text"' attribute that can be put on an RPC.
>>>>>
>>>>> Thanks,
>>>>> Phil
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>>
>>>>
>>>> --
>>>> ++ytti
>>>
>>> Hi Saku,
>>>
>>>> I don't follow you, the 'column' names are not needed, as they are in the tags?
>>>
>>> Column names are not in the tags. For example, consider a use-case
>>> where you want to print the output of "show ipv6 neighbors" similarly
>>> to table format of BSD column utility and you would like to use the
>>> same column names as the output of "show ipv6 neighbors" CLI command.
>>> One way to do this is to manually create a node-set variable for the
>>> column names:
>>>
>>> "var $column_descr := {
>>> <ipv6-nd-entry> {
>>> <ipv6-nd-neighbor-address> "IPv6 Address";
>>> <ipv6-nd-neighbor-l2-address> "Linklayer Address";
>>> <ipv6-nd-state> "State";
>>> <ipv6-nd-expire> "Exp";
>>> <ipv6-nd-isrouter> "Rtr";
>>> <ipv6-nd-issecure> "Secure";
>>> <ipv6-nd-interface-name> "Interface";
>>> }
>>> }
>>>
>>> ..and generate another node-set variable using
>>> "get-ipv6-nd-information" RPC and finally use the union operator(|) to
>>> find the longest row in each column and print the output accordingly.
>>>
>>>
>>> Phil,
>>>
>>>> Both the CLI and RPC content contain the same information, but the
>>>> CLI takes the data supplied by the RPC and displays it using rules
>>>> specified by the developer. These rules include column headers,
>>>> field titles, and other gritty little details.
>>>
>>> Thanks! That's what I suspected. Looks like for example in case of
>>> "show ipv6 neighbors", cli process calls nd6info binary which contains
>>> the column names and statically set printf format string.
>>>
>>>
>>> regards,
>>> Martin
>>
>>
>>
>> --
>> ++ytti
>
> Saku,
>
> I'm not saying it is a problem. It would simply make writing certain
> scripts bit easier and make them more dynamic. For example, if XML
> output of "show ipv6 neighbors" would contain this information(note
> the added "<ipv6-nd-columndescr>" element):
>
> <rpc-reply xmlns:junos="http://xml.juniper.net/junos/16.1R2/junos">
> <ipv6-nd-information>
> <ipv6-nd-entry>
> <ipv6-nd-columndescr>IPv6 Address</ipv6-nd-columndescr>
> <ipv6-nd-neighbor-address junos:emit="emit">
> 2001:db8:cfe:0:192:168:222:55
> </ipv6-nd-neighbor-address>
> <ipv6-nd-neighbor-l2-address>de:ad:be:ef:44:21</ipv6-nd-neighbor-l2-address>
> <ipv6-nd-state>reachable</ipv6-nd-state>
> <ipv6-nd-expire>18</ipv6-nd-expire>
> <ipv6-nd-isrouter>no</ipv6-nd-isrouter>
> <ipv6-nd-issecure>no</ipv6-nd-issecure>
> <ipv6-nd-interface-name>ge-0/0/0.0</ipv6-nd-interface-name>
> </ipv6-nd-entry>
>
> ..then one does not need to manually printf the column names or create
> an additional node-set, as I did in the explained example in my
> previous e-mail.
>
>
>> Your point is that the strings are different? CLI says 'Rtr' tag says 'isrouter'?
> Yes. If CLI command prints this:
>
> user at vMX> show ipv6 neighbors
> IPv6 Address Linklayer Address State Exp Rtr
> Secure Interface
> 2001:db8:cfe:0:192:168:222:55
> de:ad:be:ef:44:21 stale 360 no no
> ge-0/0/0.0
> 2001:db8:cfe:0:192:168:222:101
> de:ad:be:ef:69:36 stale 577 no no
> ge-0/0/0.0
> fe80::5054:ff:fec7:8a5a 52:54:00:c7:8a:5a reachable 24 yes no
> ge-0/0/0.0
> fe80::5054:ff:fec7:8a5b 52:54:00:c7:8a:5b reachable 22 yes no
> ge-0/0/0.0
> fe80::dcad:beff:feef:4421 de:ad:be:ef:44:21 stale 348 no no
> ge-0/0/0.0
> fe80::dcad:beff:feef:6936 de:ad:be:ef:69:36 stale 521 no no
> ge-0/0/0.0
>
> user at vMX>
>
> ..and op command prints this(newlines after the IPv6 addresses are removed):
>
> user at vMX> op neighbors
> IPv6 Address Linklayer Address State Exp Rtr
> Secure Interface
> 2001:db8:cfe:0:192:168:222:55 de:ad:be:ef:44:21 stale 340 no
> no ge-0/0/0.0
> 2001:db8:cfe:0:192:168:222:101 de:ad:be:ef:69:36 stale 557 no
> no ge-0/0/0.0
> fe80::5054:ff:fec7:8a5a 52:54:00:c7:8a:5a reachable 10 yes
> no ge-0/0/0.0
> fe80::5054:ff:fec7:8a5b 52:54:00:c7:8a:5b reachable 43 yes
> no ge-0/0/0.0
> fe80::dcad:beff:feef:4421 de:ad:be:ef:44:21 stale 328 no
> no ge-0/0/0.0
> fe80::dcad:beff:feef:6936 de:ad:be:ef:69:36 stale 501 no
> no ge-0/0/0.0
> user at vMX>
>
> ..then I want to keep the column names the same.
>
> However, the actual point of my question was, that where do "show ipv6
> neighbors" and similar commands take the column names and the answer
> seems to be, that this is hard-coded in the binary. For example
> nd6info in case of "show ipv6 neighbors".
>
>
> regards,
> Martin
--
++ytti
More information about the juniper-nsp
mailing list