karimra / gnmic

gNMIc is a gNMI CLI client and collector
https://gnmic.kmrd.dev
Apache License 2.0
217 stars 32 forks source link

gnmic and JunOS #561

Open VahidTa opened 2 years ago

VahidTa commented 2 years ago

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 commented 2 years ago

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

VahidTa commented 2 years ago

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:

VahidTa commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

As you can see on https://github.com/karimra/gnmic/issues/561#issue-1179386398 inside logs it shows with / prefix. However, in yaml file config https://github.com/karimra/gnmic/issues/561#issuecomment-1077585219 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 https://github.com/akarneliuk/pygnmi/issues/56

VahidTa commented 2 years ago

@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 commented 2 years ago

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

hellt commented 2 years ago

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

image

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 commented 2 years ago

@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 commented 2 years ago

@VahidTA you can ask pygnmi author to reconsider his approach to path parsing - https://github.com/akarneliuk/pygnmi/issues/56