06-10-2020 01:08 AM
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.
Solved! Go to Solution.
06-10-2020 08:52 AM
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.
06-10-2020 08:52 AM
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.
06-10-2020 10:38 AM
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):
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide