gNMI and path with both origin and YANG namespaces about pygnmi HOT 3 CLOSED

Hello @fperrin ,

sorry, was extremely busy past 3 weeks and really didn't have time to look into that earlier. What you say is an interesting point. So we build the origin as we build in accordance to gNMI specification: https://github.com/openconfig/reference/blob/master/rpc/gnmi/mixed-schema.md

I'm a little bit uneasy about adding extra arguments, as the idea to keep pygnmi as simple and as close the gNMI specification as possible. Moreover, I've read the mentioned RFC 7951 (https://datatracker.ietf.org/doc/html/rfc7951), and I don't see there any mentioning about origin at all.

having said that, is there a problem to use pygnmi with Cisco IOS as it requires the module name to be the top level key? If yes, would it mean that in all the path for Cisco IOS we need to include the module? If that is the case, probably, we can thing to add a variable to gNMIclient, which could be rfc7951 and which then alters the gnmi_path_genetator, as you explained in the second case.

Best,
Anton

from pygnmi.

Hi @akarneliuk ,

Point taken about adding extra arguments, I'll not use that approach.

I'm using pygnmi with a device (that's not released yet) that expects paths of the form described there (ie. I'm quoting that Cisco document because the device I'm using has paths of the same format, not because I'm using a Cisco device) :

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1610/b_1610_programmability_cg/gnmi_protocol.html#id_84819
An RFC 7951-specified namespace prefixing also uses the YANG module name. For example, the openconfig path to a loopback interface will be /openconfig-interfaces:interfaces/interface[name=Loopback111]/

The following example shows a gNMI path with RFC7951 namespacing:

path {
  origin: "rfc7951"
  elem {
    name: "openconfig-interface:interfaces"
  }
  elem {
    name: "interface"
    key {
      key: "name"
      value: "Loopback111"
    }
  }
}

The important points are that there is a non-default origin, and some of the path elements still have : in the name. In fact, elements besides the first one can have : in the name.

The more I think about it, the more I think this all means we can get away with a very simple change: only treat : specially in the first element to set the origin, and ignore it otherwise. I'll give that a go and update #41 accordingly.

That'd mean you can generate the path above from the string rfc7951:openconfig-interfaces:interfaces/interface[name=Loopback111].

I'm not sure about the extra variable to gNMIclient, because then it means all requests will have to use the same origin, and the document you linked hints at devices that have different parts of their tree addressed differently (I do not know of devices that require that, I certainly don't have devices that require that, but it's a possibility).

from pygnmi.

Thanks for the merge of #41 , @akarneliuk.
For my purpose, it is enough, and allows to specify the paths I need, including the examples in tests/ I included.

from pygnmi.