Details
-
Bug
-
Status: Resolved
-
Resolution: Duplicate
-
None
-
None
-
None
-
Operating System: All
Platform: All
-
4492
Description
With Helium & Lithium, I can mount and leverage RESTCONF/NETCONF yang-ext:mount with a set of network devices running in real networks today. Commercial business has been developed on this capability with "Opendaylight" branding this capability.
I am unable to mount the same network devices with the Beryllium controller.
The root cause is a NullPointerException now thrown when LeafEffectiveStatementImpl fails to check that typeEffectiveSubstatement is null.
Yes, there is an error in the yang file ... specifically no "type" child for a Leaf node, and it may be tempting to some to blame the real world network device and leave this be as a "feature" of a strict yang tools ... please don't make that mistake.
To be useful, our controller must mount real world devices which have been purchased and provisioned into real networks. These real devices can't be guaranteed to perfectly implement the spec, and especially if they passed QA with an earlier version of ODL.
I'm proposing a specific fix to check for null in this case where a leaf fails to declare a type.
> this.type = TypeUtils.getTypeFromEffectiveStatement(typeEffectiveSubstatement);
—
< this.type = (typeEffectiveSubstatement == null) ? null : TypeUtils.getTypeFromEffectiveStatement(typeEffectiveSubstatement);
I don't pretend to fully understand the side effects of properly avoiding a null pointer exception, however I'll point out that the missing "type" didn't cause any known issues in He/Li.
Attachments
Issue Links
- duplicates
-
NETCONF-232 Exclude flawed models from mount point
- Resolved