I'm sure that someone will sort this out, but if not, just for the record for everyone, what tpantelis wrote in the email linked above re. "unintended due to jersey 2 upgrade" is https://git.opendaylight.org/gerrit/#/c/72245/. If worst came to worst, and this cannot be solve in netconf within a reasonable time frame, then reverting that would restore the old behaviour, I guess. The Jersey 2 upgrade is something that Kernel Projects commiters want to keep though, so it would be much preferred if this problem can be solved.

We'd have to at least revert the aaa jersey 2 patch and maybe neutron. And coordinate that - there would breakages - it was a pain to get them merged. So it would have to be a really compelling reason to revert at this point (not something I'm willing to take on).  I don't know why CSIT doesn't just check for 404 anyway - seems safer to me then relying on specific response messages.

Test can be changed but with this regression I do not think we are conforming to RestConf Standard: https://tools.ietf.org/html/rfc8040#section-7.1

yes, tests can be changed, but I have no good estimate on the amount of work that will be. This seems like
the wrong way to be doing things.

I just tried it locally with config/toaster:toaster and it returned 404 with the expected text:

<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf"><error><error-type>application</error-type><error-tag>data-missing</error-tag><error-message>Request could not be completed because the relevant data model content does not exist </error-message></error></errors>

So I'm not seeing any issue.

Can others try it manually as well?

interesting. I'm seeing the same thing locally:

curl -u "admin:admin" http://localhost:8181/restconf/operational/itm-config:tunnel-monitor-interval
<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf"><error><error-type>application</error-type><error-tag>data-missing</error-tag><error-message>Request could not be completed because the relevant data model content does not exist </error-message></error></errors>

but in CSIT it's not that way:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-upstream-all-fluorine/102/robot-plugin/log.html.gz#s1-s4-t5-k2

any chance it could have magically been resolved just now?

FYI I saw the issue 1 time in OFP but next run was not showing it, so either it is gone or is sporadic.

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-1node-flow-services-all-fluorine/101/robot-plugin/log.html.gz#s1-s3-s2

that is a different issue. that's a 500 error, which was there for a short duration but fixed
at some point. lots of little fires happening recently.

OK, then I do not see any problem in OFP. I guess someone seeing the problem will have to set the steps to reproduce in the description of this bug.

it's right here:
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-upstream-all-fluorine/102/robot-plugin/log.html.gz#s1-s4-t5-k2

The CSIT error was "ValueError: No JSON object could be decoded". It looks like it's coming back as XML and not json.

I think the test should add a Log to dump the ${respjson} content. Also I am not sure why there is no HTTP headers set for this test.

The media type passed to us from the servlet container is wildcard ("/") which we were incorrectly filtering out so it defaulted to "application/xml "instead of "application/json". https://git.opendaylight.org/gerrit/#/c/72583/ fixes it.

That explains, thanks TomP.

patch test on c/72583 shows it worked.

thanks tpantelis