gnmic and JunOS

[VahidTa]

I test gnmic with vMX Junos and I got error below:

nmic1 | 2022/03/24 10:41:28.381807 [gnmic] target "10.1.181.92:57400", subscription sub1 rcv error: rpc error: code = InvalidArgument desc = Invalid subscription path: /openconfig-platform:components/component/cpu

I have tested same path with pygnmi and it works.

[hellt]

can you try --path openconfig-platform:/components/component/cpu?

[VahidTa]

I have tested with the path you mentioned and same error exists.

Problem is gnmic automatically adds "/" as prefix. I have tested it with pygnmi as I said with same path and it works.

My environment is docker-compose and here is docker-compose config:

subscriptions:
sub1:
paths:
- openconfig-platform:components/component/cpu
stream-mode: sample
sample-interval: 1s

[VahidTa]

I figured it out. Your path works but I changed some configs too. However, is it possible to support path format that I am using too?

[karimra]

Can you point out where does gnmic add a / as prefix ?

/openconfig-platform:components/component/cpu and openconfig-platform:components/component/cpu are parsed to different gNMI paths.

The first one gets parsed to a gNMI path with 3 path elements:
pathElems=["openconfig-platform:components", "component", "cpu"]
While the second one gets parsed to a gNMI path with an origin and 3 path elements:
origin=openconfig-platform, pathElems=["components", "component", "cpu"]

[VahidTa]

As you can see on #561 (comment) inside logs it shows with / prefix. However, in yaml file config #561 (comment) it is without / prefix.

Anyway, Roman path worked correctly. My question is why openconfig-platform:components/component/cpu path does not work as it is working on pygnmi.

[karimra]

gNMIc is not appending the /, that log message is a response from the router.
The / gets added there because of the way gNMIc parses gNMI paths from xpath which I explained in my previous comment.

I will try to detail it a bit more:
The path you are trying to set is in the format origin:pathElem1/pathElem2/pathElem3
gNMIc assumes that the first part origin:pathElem1 is a single path elem because there is no / after :.

It works with pygnmi because pygnmi assumes that the first section is the origin, followed with the pathElems, meaning that with pygnmi you will have to prepend a path with / if you want to specify a first path elem that includes a :.

There is no right or wrong here since there is no spec that dictates how a gNMI path should be formatted as xpath.

EDIT:
The relevant part from pygnmi: https://github.com/akarneliuk/pygnmi/blob/33c6fc04b7743b787f2d016e3cb9f9eed9a933fb/pygnmi/path_generator.py#L51
I might be wrong but from the function's comments it seems like it's not possible to set a first path element containing a : with pygnmi.

[VahidTa]

Thank you Karim for your description about prefix.

About the path, there is no right or wrong which you mentioned. However, I think it is better to have both formats if it is possible on gnmic.

[hellt]

@VahidTa as @karimra pointed out, if in a user-provided path /openconfig-platform:components/component/cpu pygnmi treats openconfig-platform as a path origin, then I think pygnmi is wrong here, because the first element of the path may contain a YANG prefix, that should be part of the path, and not be promoted to origin.

So my take is gnmic is more accurate here as it allows you to both set the origin in a form of my-origin:/my/path and a path with yang prefix in the first path element - /my-prefix:my/path

ADD:
I have created an issue with pygnmi to see if that is indeed the case akarneliuk/pygnmi#56

[VahidTa]

@hellt you can see that for example https://yangcatalog.org/yang-search/yang_tree/openconfig-platform@2022-02-02 also uses the path format that I mentioned first. This site is funded by IETF and I get the path from there to test the gnmic for my project.

[hellt]

@VahidTa I've asked openconfig users to see if that sensor path is not vendor-specific.

[hellt]

We had a chat with OpenConfig group and based on the answers we got I think it is safe to say that it is not correct for the tools to take a path /foo:bar/baz and promote foo as a path origin.
Origin should be encoded in a way that doesn't mangle the first path element. In gnmic this is done like foo:/pfx:bar/baz; foo here is not part of the /pfx:bar/baz path, and thus it allows to specify JSON-IETF compatible paths.

Here is a snippet of this conversation

So in my view gnmic is more accurate than pygnmi here. And the sensor paths you see on yang catalog is something that is vendor specific and is not coming from the OpenConfig

[VahidTa]

@hellt That's great and thank you for your clean answer to my concern. So, this inconsistency in tools needs to be solved because this makes it hard to use one standard path/sensor value.

[hellt]

@VahidTa you can ask pygnmi author to reconsider his approach to path parsing - akarneliuk/pygnmi#56