Open VahidTa opened 2 years ago
can you try --path openconfig-platform:/components/component/cpu
?
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:
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?
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"]
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.
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.
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.
@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
@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.
@VahidTa I've asked openconfig users to see if that sensor path is not vendor-specific.
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
@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.
@VahidTA you can ask pygnmi author to reconsider his approach to path parsing - https://github.com/akarneliuk/pygnmi/issues/56
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.