gNMI requests are malformed

[vadigreg]

Hello,

I can see a weird behavior with gNMI. Here is what I got:

        repo = Repository()
        provider = gNMIServiceProvider(repo=repo,
                                       address=args.gnmi.hostname,
                                       port=args.gnmi.port,
                                       username=args.gnmi.username,
                                       password=args.gnmi.password)
        crud = CRUDService()
        entries = crud.read(provider, Cisco_IOS_XE_wireless_wlan_cfg.WlanCfgData.WlanCfgEntries())

The output is:

2020-06-10 10:03:35,494 - ydk - INFO - Path where models are to be downloaded: /users/vadigreg/.ydk/10.51.65.177
2020-06-10 10:03:35,509 - ydk - INFO - gNMIServiceProvider Connected to 10.51.65.177 via Insecure Channel
2020-06-10 10:03:35,541 - ydk - INFO - Executing CRUD read operation on [Cisco-IOS-XE-wireless-wlan-cfg:wlan-cfg-data]
2020-06-10 10:03:35,542 - ydk - INFO - 
=============== Get Request Sent ================
path {
  origin: "Cisco-IOS-XE-wireless-wlan-cfg"
  elem {
    name: "wlan-cfg-data"
  }
  elem {
    name: "wlan-cfg-entries"
  }
}
encoding: JSON_IETF


2020-06-10 10:03:36,490 - ydk - ERROR - GetRequest failed with error:
Unsupported Path::Origin value[ cisco-ios-xe-wireless-wlan-cfg ] in Request
Traceback (most recent call last):
  File "main.py", line 59, in <module>
    entries = crud.read(provider, Cisco_IOS_XE_wireless_wlan_cfg.WlanCfgData.WlanCfgEntries())
  File "/nobackup/pyats/lib/python3.6/site-packages/ydk/services/crud_service.py", line 60, in read
    return _crud_read(provider, read_filter, False, self._crud.read)
  File "/nobackup/pyats/lib/python3.6/site-packages/ydk/services/crud_service.py", line 88, in _crud_read
    read_top_entity = crud_call(provider, top_filters)
  File "/auto/pysw/cel8x/python64/3.6.10/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/nobackup/pyats/lib/python3.6/site-packages/ydk/errors/error_handler.py", line 82, in handle_runtime_error
    _raise(_exc)
  File "/nobackup/pyats/lib/python3.6/site-packages/ydk/errors/error_handler.py", line 54, in _raise
    exec("raise exc from None")
  File "<string>", line 1, in <module>
ydk.errors.YServiceProviderError:  GetRequest failed with error:
Unsupported Path::Origin value[ cisco-ios-xe-wireless-wlan-cfg ] in Request

I actually know my box is able to reply correctly to this:

{
  "prefix": {
    "origin": "rfc7951",
    "elem": [{"name": "Cisco-IOS-XE-wireless-wlan-cfg:wlan-cfg-data"}]
  },
  "path": [{"origin": "rfc7951", "elem": [{"name": "wlan-cfg-entries"}]}],
  "type": "CONFIG",
  "encoding": "JSON_IETF",
  "action": "get_request"
}

Thanks for your help.

[yangorelik · Accepted solution]

Hello Valeri

This is documented GitHub issue, labeled as discussion. In fact it is vaguely related to YDK. The real issue is rather in specific implementation of gNMI server in IOS XE software. The current implementation of gNMI service provider in YDK is oriented on implementation of gNMI server in IOS XR, which is different and currently is not compatible with XE devices.

In my opinion use of 'rfc7951' as origin in the path does not have any sense. It is not a part of YANG model and therefore cannot be derived from it. Hence YDK will not be able to support such path format. At the time of opening the discussions I have addressed this issue to gNMI server in IOS XE developers. Unfortunately they ignored my arguments.

I wonder if XE device would accept path without origin. If yes, then YDK could be enhanced to work with both path formats. You also can alter locally the YDK code in order to work specifically with XE devices.

[vadigreg]

Hi Yan,

thanks for your answer. I investigated a bit and my understanding is that prefixing can assume several values in IOS-XE (see "gNMI Namespace" at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1610/b_1610_programmability_cg/gnmi_protocol.html):

• No origin (default) is equal to "openconfig" and can be used only with openconfig models. In these cases path is not prefixed.
• "rfc7951", in this case module name is used as a prefix to the path.
• "legacy", in this case the YANG module prefix as defined in the YANG module definition is used for path prefixing (only for releases prior to 16.10).

I had a look at design documents and code, I can see valid reasons for this choice. This is probably why your ask wasn't accepted.

This can probably be handled in a way that doesn't break current implementation. In example by providing an enum prefixing_type (e.g., IOSXR, IOSXE_LEGACY, IOSXE_OPENCONFIG, IOSXE_RFC7951). Perhaps passed to the gNMISession ctor and gNMIServiceProvider ctor? Ofc default value should be IOSXR for backward compatibility.

Probably gNMI isn't really needed to me, so for now I attempted a quick&dirty patch just for demo-ing YDK capabilities to my team. However if I ever manage to bring the patch to a deliverable state I will share it with you via GitHub, hoping that it could be of any use for the broader community.

Thanks again,

Val