https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-86 netconf <p>With Helium &amp; 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.</p> <p>I am unable to mount the same network devices with the Beryllium controller.</p> <p>The root cause is a NullPointerException now thrown when LeafEffectiveStatementImpl fails to check that typeEffectiveSubstatement is null.</p> <p>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.</p> <p>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.</p> <p>I'm proposing a specific fix to check for null in this case where a leaf fails to declare a type.</p> <p>&gt; this.type = TypeUtils.getTypeFromEffectiveStatement(typeEffectiveSubstatement);<br/> &#8212;<br/> &lt; this.type = (typeEffectiveSubstatement == null) ? null : TypeUtils.getTypeFromEffectiveStatement(typeEffectiveSubstatement);</p> <p>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.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-86

Real world network devices NETCONF mounted Lithium won't mount Beryllium

Bug Resolved Duplicate Unassigned James Gregory Hall Fri, 16 Oct 2015 14:16:31 +0000 Fri, 15 Mar 2019 22:22:15 +0000 Fri, 22 Jul 2016 07:55:12 +0000 netconf 0 6 <p>TypeUtils.getTypeFromEffectiveStatement() was edited in Change 28478.<br/> Was that Change a cause (or possibly a fix) of this Bug?</p> <p>Please talk to the device vendor to fix their models, as type statement is absolutely critical to correct interpretation of the data. It is also critical that invalid models get fixed, otherwise we will end up in interoperability hell, as different systems will end up fixing flawed models in different ways, thus leading to incompatible behavior.</p> <p>In the meantime, you can deploy a fixed-up version of the model in the NETCONF cache, so it will not get pulled from the device.</p> <p>Downgrading priority to normal, since this is not blocking an ODL project as far as I can tell.</p> <p>Eventually the vendor will fix the issue, and then eventually all customers will upgrade all devices to make this all go away ... but that timeline is beyond our control.</p> <p>This is blocking the use of the controller to mount network devices which are being mounted by Helium &amp; Lithium based controllers.</p> <p>&gt; This is blocking the use of the controller to mount network devices <br/> &gt; which are being mounted by Helium &amp; Lithium based controllers.</p> <p>Statement is not correct, this is only blocking specific vendor and only in case broken model is downloaded from device. </p> <p>&gt; In the meantime, you can deploy a fixed-up version of the model in <br/> &gt; the NETCONF cache, so it will not get pulled from the device.</p> <p>Work-around for such devices (without introducing validation regression in parser)<br/> is to load modified models in cache/schema folder of OpenDaylight controller,<br/> which is used to provide models without downloading them from device.</p> <p>If such "exception" for non-strictness should be part of parser, not enforcing<br/> correct behaviour will allow for additional models like the one you mentioned to be created.</p> <p>Cleaner way will be introduction of STRICT and COMPATIBILITY modes into parser, where<br/> one will be used during compile time and other in runtime, but introducing such APIs and rule-sets (and chosing which part of YANG do not enforce in COMPATIBILITY mode) will require lot of work and redesign of some of API contracts.</p> <p>Also behaviour of COMPATIBILITY fixes is left out to dispuse - how parser should render effective model from which NETCONF, RESTCONF, MD-SAL derives it's behaviour and are this choices really right?<br/> Eg. in your use-case it may falling back to string be right choice, but what if other system with same issue was implemented to expect is as type empty or type identityref?</p> <p>Robert's idea allows for users, integrators and vendors to provide fixed models and to sideload them to OpenDaylight without modifying actual device and to specify such behaviour on per-model basis, instead of creating "default" rule for specific types of not honoring YANG.</p> <p>As discussed on the MD-SAL meeting, the problem here is that a single model which fails to parse renders the entire mount point unusable. This problem can be solved acceptably by excluding the model from the resulting schema context, which is something the NETCONF SB plugin can do based on its configuration (either global or for that particular element).</p> <p>The other issue raised is the fact the mount point access from RESTCONF NB to NETCONF SB forces data validation, which breaks with devices which do not enforce their own models (like allowing an out-of-range value to be configured) &#8211; leading to get-config failing. This is needed for the ability to project the data on the NB in both JSON and XML, but could potentially be addressed by re-architecting the RESTCONF/NETCONF interactions.</p> <p>An idea of 'sloppy' mount points was discussed, which requires some level of design and changes to the MD-SAL APIs to expose how sloppy the mount point is being, so its interactions with the rest of the system can be properly guarded &#8211; for example blocking MD-SAL applications from seeing non-conformant data, so they do not break on it.</p> <p>Since the two immediate problems can (and should) be addressed within the NETCONF project, I am moving this issue there.</p> Duplicate NETCONF-232 Development External issue ID 4492 External issue URL Issue Type Rank 0|i01wdb: