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/TSC-179 tsc <p>The <a href="https://git.opendaylight.org/gerrit/#/q/topic:neon-mri+(status:open+OR+status:merged)" class="external-link" target="_blank" rel="nofollow noopener">Neon MRI patches</a> (<a href="https://jira.opendaylight.org/browse/TSC-132" title="Neon MRI Integration Window" class="issue-link" data-issue-key="TSC-132"><del>TSC-132</del></a>) were merged despite there never having been full CSIT passing in projects such as genius and netvirt.</p> <p>The currently known problem (but there may of course still be others lurking) is a <tt>IncorrectNestingException</tt>. <a href="https://jira.opendaylight.org/browse/INFRAUTILS-58" title="JobCoordinator does not retain Thread Context Class Loader" class="issue-link" data-issue-key="INFRAUTILS-58"><del>INFRAUTILS-58</del></a> implements a suggestion how to fix that, but it didn't work. <a href="https://jira.opendaylight.org/browse/MDSAL-379" title="Attempt to recover bindings when TCCL is incorrect" class="issue-link" data-issue-key="MDSAL-379"><del>MDSAL-379</del></a> has a possible fix (to be confirmed) for a possible MDSAL v3.0.2, which is not yet released.</p> <p>The goal of this issue is to bump all managed projects from MDSAL 3.0.1 to 3.0.2-SNAPSHOT and run a multipatch job with CSIT to see if <a href="https://jira.opendaylight.org/browse/MDSAL-379" title="Attempt to recover bindings when TCCL is incorrect" class="issue-link" data-issue-key="MDSAL-379"><del>MDSAL-379</del></a> has solved the IncorrectNestingException.</p> TSC-179

Genius CSI broken by ietf-interface revision misalignment

Bug Medium Resolved Done Michael Vorburger Michael Vorburger Thu, 1 Nov 2018 17:22:13 +0000 Tue, 30 Apr 2019 06:14:26 +0000 Mon, 5 Nov 2018 09:53:45 +0000 0 6 <p>using <a href="https://wiki.opendaylight.org/view/BumpingReleasedProjectVersions" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/BumpingReleasedProjectVersions</a>,</p> <p>created new changes on <a href="https://git.opendaylight.org/gerrit/#/q/topic:neon-mri+status:open" class="external-link" target="_blank" rel="nofollow noopener">topic neon-mri</a> to "bump mdsal from 3.0.1 to 3.0.2-SNAPSHOT",</p> <p>and <a href="https://jenkins.opendaylight.org/releng/view/integration/job/integration-multipatch-test-neon/104/" class="external-link" target="_blank" rel="nofollow noopener">running a multipatch build</a> ...</p> <p>Results don't look much better</p> <p><a href="https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-neon/89/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-neon/89/</a></p> <p>&gt; Results don't look much better</p> <p>Yup, indeed <tt>IncorrectNestingException</tt> is still there on <a href="https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-upstream-all-neon/89/odl_1/odl1_karaf.log.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-upstream-all-neon/89/odl_1/odl1_karaf.log.gz</a> ... <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> so <a href="https://jira.opendaylight.org/browse/MDSAL-379" title="Attempt to recover bindings when TCCL is incorrect" class="issue-link" data-issue-key="MDSAL-379"><del>MDSAL-379</del></a> has not solved the IncorrectNestingException.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> (and <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> as the other MDSAL committer) as this point, wouldn't the right thing to do to simply revert whatever in mdsal changed class loading related to augmentations? We're (very) late in the Neon-MRI bump, and there is a real risk that projects now start to push back and revert everything back; it was discussed in the TSC call yesterday - and that would be a shame, no?</p> <p>I have no idea what change in MDSAL caused this problem, and why it was made, but weighed against the overall Neon MRI bump advantages globally, doubt it's critical enough to justify further blocking projects? (E.g. netvirt &amp; genius are still completely paralyzed, because of this.)</p> <p>I have no idea what change either if it was even a change in mdsal. Looking at DataObjectCodecContext, there's been no relevant changes recently so this may be due to some upstream change (yangtools or odlparent even). Unless <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> has any idea what change could have caused this, I think we're going to have to instrument debug in DataObjectCodecContext et al.</p> <p>There is no change in MD-SAL which would cause this issue, simply because MD-SAL works as designed. The problem is in downstreams not agreeing which revision of ietf-interfaces to use, leading to issues known from the ietf-inet-types two years back.</p> <p>Specifically sort out:</p> <p> </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>nite@nitebug : ~/odl/autorelease on master $ find . -name pom.xml | xargs fgrep 8343 ./bgpcep/bgp/openconfig-api/pom.xml:            &lt;artifactId&gt;rfc8343&lt;/artifactId&gt; ./bgpcep/config-loader/config-loader-impl/pom.xml:            &lt;artifactId&gt;rfc8343&lt;/artifactId&gt; ./lispflowmapping/mappingservice/neutron/pom.xml:      &lt;artifactId&gt;rfc8343&lt;/artifactId&gt; </pre> </div></div> <p>vs.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>nite@nitebug : ~/odl/autorelease on master $ find . -name pom.xml | xargs fgrep 7223 ./genius/itm/itm-api/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/itm/itm-impl/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/interfacemanager/interfacemanager-api/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/interfacemanager/interfacemanager-impl/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/arputil/arputil-impl/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/arputil/arputil-api/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/alivenessmonitor/alivenessmonitor-impl/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./genius/ipv6util/api/pom.xml:      &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./bgpcep/features/bgp/odl-bgpcep-bgp-rib-api/pom.xml:            &lt;artifactId&gt;odl-mdsal-model-rfc7223&lt;/artifactId&gt; ./netvirt/vpnmanager/api/pom.xml:            &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./netvirt/elanmanager/api/pom.xml:            &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./netvirt/aclservice/api/pom.xml:            &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; ./netvirt/fibmanager/api/pom.xml:            &lt;artifactId&gt;rfc7223&lt;/artifactId&gt; </pre> </div></div> <p>or use revision imports in the projects which are using rfc7223 and everything will just work.</p> <p> </p> <p>At any rate this is <b>NOT</b> an MD-SAL issue and therefore there is no need to bump/revert chaos.</p> <p>My recommendation, as the MD-SAL PTL is that:</p> <ul> <li>all downstreams use RFC7223 as that is the Fluorine baseline model</li> <li>all downstreams agree on a migration plan to RFC8343.</li> </ul> <p>MD-SAL has no skin in this particular discussion at this time, but we certainly would like to stop shipping the RFC7223 revision as soon as it is convenient.</p> <p>Thanks <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a>! </p> <p>Not sure what is to be taken care when we switch from rfc7223 to rfc8343, but I have blindly pushed a patch changing the same in genius poms. <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Is there a documentation anywhere which tells the right way to migrate?</p> <p>It also involves switching from rev140508 to rev180220 of the relevant YANG models, and some other changes which I haven’t figured out yet.</p> <p>Presumably this also needs revising all dependent models...</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vorburger" class="user-hover" rel="vorburger">vorburger</a> I think all of the 3.0.2-SNAPSHOT patches should be removed from neon-mri topic and possibly abandoned.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=k.faseela" class="user-hover" rel="k.faseela">k.faseela</a>, <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=thapar" class="user-hover" rel="thapar">thapar</a>, <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=shague" class="user-hover" rel="shague">shague</a>, <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jluhrsen" class="user-hover" rel="jluhrsen">jluhrsen</a>, <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=skitt" class="user-hover" rel="skitt">skitt</a> can you double re-confirm that the <tt>IncorrectNestingException</tt> which this issue was about is fully resolved now and non of you have any objections if we close this issue now? (I'm slightly confused and asking specifically because of the new <a href="https://git.opendaylight.org/gerrit/#/c/77455/" class="external-link" target="_blank" rel="nofollow noopener">c/77455</a> change which is open against both this Jira as well as <a href="https://jira.opendaylight.org/browse/TSC-123" title="Adopt NMDA-compatible versions of ietf-interfaces and ietf-ip" class="issue-link" data-issue-key="TSC-123">TSC-123</a> ... is that still part of and required by the Neon MRI bump, or possible future work, at this stage?)</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> sure, I'll abandon all of the 3.0.2-SNAPSHOT patches when we close this issue.</p> <p>IncorrectNestingException is gone now.. There is one more failure left, for which we are trying a fix now.</p> <p>Yes, not needed. Reverting lispflow andbgpcep to rfc7223 avoids the problem.</p> <p>OK, in that case, closing this issue now (and have abandoned the mdsal 3.0.2-SNAPSHOT bumps); great we're past this.</p> Blocks TSC-132 Relates TSC-123 INFRAUTILS-58 MDSAL-379 Development Rank 0|i03k4f: