using https://wiki.opendaylight.org/view/BumpingReleasedProjectVersions,

created new changes on topic neon-mri to "bump mdsal from 3.0.1 to 3.0.2-SNAPSHOT",

and running a multipatch build ...

Results don't look much better

https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-neon/89/

> Results don't look much better

Yup, indeed IncorrectNestingException is still there on https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-upstream-all-neon/89/odl_1/odl1_karaf.log.gz ...  so MDSAL-379 has not solved the IncorrectNestingException.

rovarga (and tpantelis 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?

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 & genius are still completely paralyzed, because of this.)

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 rovarga has any idea what change could have caused this, I think we're going to have to instrument debug in DataObjectCodecContext et al.

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.

Specifically sort out:

nite@nitebug : ~/odl/autorelease on master $ find . -name pom.xml | xargs fgrep 8343
./bgpcep/bgp/openconfig-api/pom.xml:            <artifactId>rfc8343</artifactId>
./bgpcep/config-loader/config-loader-impl/pom.xml:            <artifactId>rfc8343</artifactId>
./lispflowmapping/mappingservice/neutron/pom.xml:      <artifactId>rfc8343</artifactId>

vs.

nite@nitebug : ~/odl/autorelease on master $ find . -name pom.xml | xargs fgrep 7223
./genius/itm/itm-api/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/itm/itm-impl/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/interfacemanager/interfacemanager-api/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/interfacemanager/interfacemanager-impl/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/arputil/arputil-impl/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/arputil/arputil-api/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/alivenessmonitor/alivenessmonitor-impl/pom.xml:      <artifactId>rfc7223</artifactId>
./genius/ipv6util/api/pom.xml:      <artifactId>rfc7223</artifactId>
./bgpcep/features/bgp/odl-bgpcep-bgp-rib-api/pom.xml:            <artifactId>odl-mdsal-model-rfc7223</artifactId>
./netvirt/vpnmanager/api/pom.xml:            <artifactId>rfc7223</artifactId>
./netvirt/elanmanager/api/pom.xml:            <artifactId>rfc7223</artifactId>
./netvirt/aclservice/api/pom.xml:            <artifactId>rfc7223</artifactId>
./netvirt/fibmanager/api/pom.xml:            <artifactId>rfc7223</artifactId>

or use revision imports in the projects which are using rfc7223 and everything will just work.

At any rate this is NOT an MD-SAL issue and therefore there is no need to bump/revert chaos.

My recommendation, as the MD-SAL PTL is that:

• all downstreams use RFC7223 as that is the Fluorine baseline model
• all downstreams agree on a migration plan to RFC8343.

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.

Thanks rovarga! 

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.

Is there a documentation anywhere which tells the right way to migrate?

It also involves switching from rev140508 to rev180220 of the relevant YANG models, and some other changes which I haven’t figured out yet.

Presumably this also needs revising all dependent models...

vorburger I think all of the 3.0.2-SNAPSHOT patches should be removed from neon-mri topic and possibly abandoned.

k.faseela, thapar, shague, jluhrsen, skitt can you double re-confirm that the IncorrectNestingException 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 c/77455 change which is open against both this Jira as well as TSC-123 ... is that still part of and required by the Neon MRI bump, or possible future work, at this stage?)

rovarga sure, I'll abandon all of the 3.0.2-SNAPSHOT patches when we close this issue.

IncorrectNestingException is gone now.. There is one more failure left, for which we are trying a fix now.

Yes, not needed. Reverting lispflow andbgpcep to rfc7223 avoids the problem.

OK, in that case, closing this issue now (and have abandoned the mdsal 3.0.2-SNAPSHOT bumps); great we're past this.