search

CiscoDevNet / ydk-gen

Generate model-driven APIs from YANG models
http://ciscodevnet.github.io/ydk-gen/
Apache License 2.0
137 stars 74 forks source link

YModelError when identityref uses module prefix instead of module name #1037

Closed csrm7 closed 3 years ago

csrm7 commented 3 years ago

Issue Description

YDK throws "YModelError" if identityref uses module prefix instead of module name. Please refer to the logs below where "oc-alarm-types" is prefix for "openconfig-alarm-types"

Creating this enhancement request as suggested in YDK community.

reading-system-alarms-libyang-error-failed-to-resolve/m-p/4194967

Currently model API generated by YDK does not have mapping of module prefixes to module names and therefore there is no means to find module name by its prefix, hence the YModelError. New development is needed. Please file new issue in ydk-gen GitHub.

Script

oc_system = openconfig_system.System()
alarms = crud.read(provider, oc_system.alarms)

Logs (gNMI)

Cannot find model with module name 'openconfig-aaa'
Cannot find model with module name 'openconfig-aaa'
Executing CRUD read operation on [openconfig-system:system]

=============== Get Request Sent ================
path {
  origin: "openconfig-system"
  elem {
    name: "system"
  }
  elem {
    name: "alarms"
  }
}
encoding: JSON_IETF

============= Get Response Received =============
notification {
  timestamp: 1607427249044136202
  update {
    path {
      origin: "openconfig-system"
      elem {
        name: "system"
      }
      elem {
        name: "alarms"
      }
    }
    val {
      json_ietf_val: "{\"alarm\":[{\"id\":\"SM/HW_ENVMON_PEM_ALARM/22#CHASSIS/LCC/1\",\"state\":{\"id\":\"SM/HW_ENVMON_PEM_ALARM/22#CHASSIS/LCC/1\",\"resource\":\"0\",\"text\":\"Power Module redundancy lost.\",\"time-created\":\"1607382067\",\"severity\":\"oc-alarm-types:MAJOR\",\"type-id\":\"oc-alarm-types:HW_ENVMON_PEM_LVL_RED_LOST\"}},{\"id\":\"SM/HW_ENVMON_FAN_ALARM/201#CHASSIS/LCC/1\",\"state\":{\"id\":\"SM/HW_ENVMON_FAN_ALARM/201#CHASSIS/LCC/1\",\"resource\":\"0\",\"text\":\"Fan: One or more LCs missing, running fans at max speed.\",\"time-created\":\"1607382086\",\"severity\":\"oc-alarm-types:CRITICAL\",\"type-id\":\"oc-alarm-types:HW_ENVMON_RM_LC_REMOVAL\"}},{\"id\":\"SYSTEM/HW_ERROR/82#CHASSIS/LCC/1:CONTAINER/LC/3\",\"state\":{\"id\":\"SYSTEM/HW_ERROR/82#CHASSIS/LCC/1:CONTAINER/LC/3\",\"resource\":\"0/2\",\"text\":\"Verification of SUDI Certificate Failed On LC.\",\"time-created\":\"1607382102\",\"severity\":\"oc-alarm-types:MAJOR\",\"type-id\":\"oc-alarm-types:LC_SUDI_FAILURE\"}},{\"id\":\"XR/SW_MISC_ERR/1#CHASSIS/LCC/1:CONTAINER/CC/1:MODULE/RP/1:MODULE/FPGA/4\",\"state\":{\"id\":\"XR/SW_MISC_ERR/1#CHASSIS/LCC/1:CONTAINER/CC/1:MODULE/RP/1:MODULE/FPGA/4\",\"resource\":\"0/RP0\",\"text\":\"One Or More FPDs Need Upgrade Or Not In Current State\",\"time-created\":\"1607382108\",\"severity\":\"oc-alarm-types:MAJOR\",\"type-id\":\"oc-alarm-types:FPD_NEED_UPGRADE_ALARM\"}},{\"id\":\"XR/HW_G709/18#CHASSIS/LCC/1:CONTAINER/LC/3:MODULE/TRC/1:MODULE/SLICE/0:PORT/OPTICS/5:PORT/G709/2:PORT/G709/2\",\"state\":{\"id\":\"XR/HW_G709/18#CHASSIS/LCC/1:CONTAINER/LC/3:MODULE/TRC/1:MODULE/SLICE/0:PORT/OPTICS/5:PORT/G709/2:PORT/G709/2\",\"resource\":\"ODU20/2/0/5/2\",\"text\":\"Path Monitoring Alarm Indication Signal\",\"time-created\":\"1607427024\",\"severity\":\"oc-alarm-types:WARNING\",\"type-id\":\"oc-alarm-types:G709_PM_AIS\"}},{\"id\":\"XR/HW_ETHERNET/121#CHASSIS/LCC/1:CONTAINER/LC/3:MODULE/TRC/1:MODULE/SLICE/0:PORT/OPTICS/5:PORT/ETHERNET/1\",\"state\":{\"id\":\"XR/HW_ETHERNET/121#CHASSIS/LCC/1:CONTAINER/LC/3:MODULE/TRC/1:MODULE/SLICE/0:PORT/OPTICS/5:PORT/ETHERNET/1\",\"resource\":\"TenGigECtrlr0/2/0/5/1\",\"text\":\"Local Fault\",\"time-created\":\"1607427025\",\"severity\":\"oc-alarm-types:MAJOR\",\"type-id\":\"oc-alarm-types:ETHER_LF\"}}]}"
    }
  }
}
error {
}

Get Operation Succeeded
Cannot find model with module name 'Fan'
Data is invalid according to the yang model. Libyang error: Data model "Fan" not found.
Data is invalid according to the yang model. Libyang error: Failed to resolve identityref "oc-alarm-types:MAJOR". Path: '/openconfig-system:system/alarms/alarm[id='SM/HW_ENVMON_PEM_ALARM/22#CHASSIS/LCC/1']/state/severity'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/ydk_vne/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 "/root/ydk_vne/lib/python3.6/site-packages/ydk/services/crud_service.py", line 88, in _crud_read
    read_top_entity = crud_call(provider, top_filters)
  File "/usr/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/root/ydk_vne/lib/python3.6/site-packages/ydk/errors/error_handler.py", line 82, in handle_runtime_error
    _raise(_exc)
  File "/root/ydk_vne/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.YModelError:  Failed to resolve identityref "oc-alarm-types:MAJOR". Path: /openconfig-system:system/alarms/alarm[id='SM/HW_ENVMON_PEM_ALARM/22#CHASSIS/LCC/1']/state/severity

Logs (Netconf)

Data is invalid according to the yang model. Libyang error: Invalid value "oc-alarm-types:CRITICAL" in "severity" element. Path: '/openconfig-system:system/alarms/alarm[id='SM/HW_ENVMON_FAN_ALARM/201#CHASSIS/LCC/1']/state/severity'
Traceback (most recent call last):
  File "read_alarms.py", line 38, in <module>
    alarms = crud.read(provider, oc_system.alarms)
  File "/root/ydk_vne/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 "/root/ydk_vne/lib/python3.6/site-packages/ydk/services/crud_service.py", line 88, in _crud_read
    read_top_entity = crud_call(provider, top_filters)
  File "/usr/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/root/ydk_vne/lib/python3.6/site-packages/ydk/errors/error_handler.py", line 82, in handle_runtime_error
    _raise(_exc)
  File "/root/ydk_vne/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.YModelError:  Invalid value "oc-alarm-types:CRITICAL" in "severity" element. Path: /openconfig-system:system/alarms/alarm[id='SM/HW_ENVMON_FAN_ALARM/201#CHASSIS/LCC/1']/state/severity
Disconnected from device

System Information

# pip freeze | grep ydk
ydk==0.8.5
ydk-models-bo-openconfig==7.3.1
ydk-models-ietf==0.1.5.post2
ydk-models-openconfig==0.1.8
ydk-service-gnmi==0.4.0.post5

# uname -a
Linux         4.15.0-123-generic #126-Ubuntu SMP Wed Oct 21 09:40:11 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ygorelik commented 3 years ago

I am afraid that device is sending wrong response, which should not use prefixes instead of full module names. Suggest to talk to device engineering department and request to correct the issue.

NOTE: The YANG RFC-6020 defines the following constraints for the prefix statement:

All prefixes, including the prefix for the module itself MUST be unique within the module or submodule.

and lower for the import statement:

The mandatory "prefix" substatement assigns a prefix for the imported module that is scoped to the importing module or submodule. Multiple "import" statements may be specified to import from different modules.

That means the prefix cannot uniquely identify the module. The same module imported to other modules can have different prefixes defined in corresponding import statements. Therefore there is no way to provide mapping, which could uniquely identify module from given prefix.

csrm7 commented 3 years ago

@ygorelik Thank you for your time and clarification. I had it fixed from the device engineering.