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-113 netconf <p>In Beryllium, <del>all</del> jobs were failing due to Restconf getting stuck in http code 401.<br/> Investigation suggests it is not an AAA bug, it is Yangtools unable to move on when encountering invalid Yang modules.</p> <p>The situation with <del>all</del> jobs can be solved in integration/distribution by removing offending features; but as ODL grows, it would be good to make the core more resistant to low-quality components.</p> <p>Search for "Failed to parse YANG from source" in (long) <span class="error">&#91;0&#93;</span> to see current offending projects, see <span class="error">&#91;1&#93;</span> for the integration/distribution fix (which perhaps will be merged as 31720 instead).</p> <p><span class="error">&#91;0&#93;</span> <a href="https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-throughpcep-all-beryllium/83/consoleFull" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-throughpcep-all-beryllium/83/consoleFull</a><br/> <span class="error">&#91;1&#93;</span> <a href="https://git.opendaylight.org/gerrit/31715" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/31715</a></p> <p>Operating System: All<br/> Platform: All</p> NETCONF-113

Incorrect Yang models should not prevent functionality from unrelated components

Bug Confirmed Unresolved Unassigned Vratko Polak Mon, 21 Dec 2015 19:00:12 +0000 Mon, 4 May 2020 22:52:39 +0000 restconf-nb 0 4 <p>All interfaces required for RESTCONF to exclude specified models are available, making this a non-yangtools issue.</p> <p>Note that, though, that should this really be implemented, RESTCONF has to emit a very stern warning and (some) test jobs have to check for this warning and fail tests. Otherwise this problem will not be detected and we will end up shipping a broken release.</p> <p>&gt; (some) test jobs have to check for this warning</p> <p>Agreed. We can add such check to deploy test job (which is planned to be run during </p> {project} <p><del>merge</del>* job execution).<br/> That should cover everything under odl-integration-all.</p> <p>See these two lines <span class="error">&#91;0&#93;</span> for what is checked already (the code may be move someplace else later).</p> <p><span class="error">&#91;0&#93;</span> <a href="https://git.opendaylight.org/gerrit/gitweb?p=releng/builder.git;a=blob;f=jjb/integration/include-raw-integration-deploy-controller-verify.sh;h=ff1fd97a60fdf8c6eac7c927ca93c14ed8d1b103;hb=HEAD#l97" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/gitweb?p=releng/builder.git;a=blob;f=jjb/integration/include-raw-integration-deploy-controller-verify.sh;h=ff1fd97a60fdf8c6eac7c927ca93c14ed8d1b103;hb=HEAD#l97</a></p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a>, this is a really old ticket at this point. Are we past this kind of problem now, or<br/> something more to do here. If I understand correctly, the issue is that a bad yang model<br/> would bork feature installation and break the entire distribution. Originally our CSIT was<br/> noticing the symptom of 401 unauthorized. Are we still at risk of this?</p> Development External issue ID 4828 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01wjb: