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/CONTROLLER-643 controller <p>There's a test in NetconfDeviceSchemaProviderFactory.java which (I believe) is intended to check if a device has not provided any schemas:</p> <p> Preconditions.checkState(sourceContext.getValidSources().isEmpty() == false,<br/> "%s: Unable to create schema context, no sources provided by device", id);</p> <p>however this check only fails if the ~/cache/schema directory is completely empty. If there are files in the directory which were provided by another device then the check "fails to fail" and the device is mounted despite failing to provide any sources.</p> <p>Is this intentional?</p> <p>Operating System: Linux<br/> Platform: PC</p> CONTROLLER-643

OpenDaylight "fails to fail" on mounting device which doens't provide schemas if there are other schemas in cache

Bug Resolved Won't Do Unassigned Giles Heron Wed, 23 Jul 2014 21:25:00 +0000 Tue, 25 Jul 2023 08:24:01 +0000 Wed, 25 Mar 2015 10:04:34 +0000 netconf 0 5 <p>Hi Giles,<br/> intention there is as following:</p> <p>If device does not implement ietf-netconf-monitoring, we still looks up for<br/> possible models in cache/schema because they could be sideloaded or discovered from other devices and thus this makes device able to export mount even<br/> if it did not provided schemas.</p> <p>ah, ok. </p> <p>so we just check for any one of the models supported being in the cache?</p> <p>did we consider checking for all of them? or just not bothering to check? I mean if one module is there how much better is that than none?</p> <p>So current behaviour is to load as much as possible models,<br/> the missing ones are not loaded, and netconf device is connected<br/> with limited capabilities.</p> <p>The behaviour of netconf connector is to try to get sources from cache / other devices if they have same revision of same model.</p> <p>Hi Giles,</p> <p>So this is expected behavior as sal-netconf-connector tries to build the SchemaContext from the biggest possible subset of sources. Netconf-connector logs the issues with resolving sources and recently, it also writes the problematic sources into the datastore and they are available using restconf in topology model e.g. <a href="http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/</a></p> <p>So I would close this issue as expected behavior, what do you say ?</p> <p>This is expected behaviour, netconf node in the netconf topology now lists all the schemas that could not be used.</p> Development External issue ID 1408 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02lnz: