OpenDaylight JIRA

OpenDaylight JIRA https://jira.opendaylight.org This file is an XML representation of an issue en-us

8.20.10

820010

22-06-2022

[NETCONF-546] 404 returning empty response https://jira.opendaylight.org/browse/NETCONF-546 netconf <p><a href="https://lists.opendaylight.org/pipermail/netconf-dev/2018-June/001836.html" class="external-link" target="_blank" rel="nofollow noopener">email discussion</a></p> <p>this is now causing failures in CSIT jobs, like <a href="https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-fluorine/" class="external-link" target="_blank" rel="nofollow noopener">this</a></p> <p>some of these jobs are used to verify code in the integration/test project.</p> <p>some of these jobs are used as gates for other projects. Specifically, the genius project<br/> has a patch test they use to gate their patches.</p> NETCONF-546

404 returning empty response

Bug Highest Resolved Done Jakub Toth Jamo Luhrsen Fri, 1 Jun 2018 17:55:21 +0000 Fri, 1 Jun 2018 21:14:06 +0000 Fri, 1 Jun 2018 21:14:06 +0000 0 4 <p>I'm sure that someone will sort this out, but if not, just for the record for everyone, what <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> wrote in the email linked above re. "unintended due to jersey 2 upgrade" is <a href="https://git.opendaylight.org/gerrit/#/c/72245/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/72245/</a>. 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.</p> <p>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.</p> <p>Test can be changed but with this regression I do not think we are conforming to RestConf Standard: <a href="https://tools.ietf.org/html/rfc8040#section-7.1" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc8040#section-7.1</a></p> <p>yes, tests can be changed, but I have no good estimate on the amount of work that will be. This seems like<br/> the wrong way to be doing things.</p> <p>I just tried it locally with config/toaster:toaster and it returned 404 with the expected text:</p> <p><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></p> <p>So I'm not seeing any issue.</p> <p>Can others try it manually as well?</p> <p>interesting. I'm seeing the same thing locally:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">curl -u <span class="code-quote">"admin:admin"</span> http:<span class="code-comment">//localhost:8181/restconf/operational/itm-config:tunnel-monitor-interval </span><errors xmlns=<span class="code-quote">"urn:ietf:params:xml:ns:yang:ietf-restconf"</span>><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></pre> </div></div> <p>but in CSIT it's not that way:</p> <p><a href="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" class="external-link" target="_blank" rel="nofollow noopener">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</a></p> <p>any chance it could have magically been resolved just now?</p> <p>FYI I saw the issue 1 time in OFP but next run was not showing it, so either it is gone or is sporadic.</p> <p><a href="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" class="external-link" target="_blank" rel="nofollow noopener">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</a></p> <p>that is a different issue. that's a 500 error, which was there for a short duration but fixed<br/> at some point. lots of little fires happening recently.</p> <p>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.</p> <p>it's right here:<br/> <a href="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" class="external-link" target="_blank" rel="nofollow noopener">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</a></p> <p>The CSIT error was "ValueError: No JSON object could be decoded". It looks like it's coming back as XML and not json.</p> <p>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.</p> <p>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". <a href="https://git.opendaylight.org/gerrit/#/c/72583/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/72583/</a> fixes it.</p> <p>That explains, thanks TomP.</p> <p><a href="https://jenkins.opendaylight.org/releng/job/genius-csit-1node-gate-all-fluorine/73/" class="external-link" target="_blank" rel="nofollow noopener">patch test</a> on c/72583 shows it worked.</p> <p>thanks <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a></p> Blocks GENIUS-166 Development Rank 0|i03f87: