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-398 netconf <p>This is a kind of general problem, because more than one suite enters the state when a node starts to respond with http response 401 (unauthorized). Few bugs may already be opened for problems related to the node isolation, but these problems result in odl node response 401.<br/> At the moment i am unaware of how to recover from this state, but it is definitely possible, because every next suite behaves well at the start.</p> <p>Job: <a href="https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-only-carbon/626/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-only-carbon/626/</a></p> <p>Suite: Rpc Provider Partition And Heal</p> <ul class="alternate" type="square"> <li>2 nodes have rpc registered, the 3rd one no</li> <li>the one without rpc is isolated and we expect status code 501 when rpc called, but 401 is returned</li> </ul> <p>Suite: Action Provider Partition And Heal<br/> A node with routed rpc is isolated. The rpc is then called on that node and status 200 is expected. 401 is returned.</p> <p>Suite: Partition And Heal (Clustering Singleton)<br/> Singleton constant is installed on each node and then the owner node is isolated. When requesting odl-mdsal-lowlevel-target:get-singleton-constant on isolated node, 501 is expected, 401 is returned.</p> <p>This may not be the single problem, but all is related to node isolation process.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-398

Carbon: odl respond with http status 401 in various suites

Bug Resolved Duplicate Jakub Toth Peter Gubka Tue, 11 Apr 2017 14:50:45 +0000 Fri, 15 Mar 2019 22:22:40 +0000 Tue, 18 Apr 2017 12:41:51 +0000 restconf-nb 0 4 <p>401 points to an HTTP authentication issue, ie AAA. This is not related to clustering. Perhaps AAA is somehow affected by node isolation or it's an issue on the robot side (perhaps it's not sending the proper authentication header?). Also does it fail fast if it doesn't immediately receive 501? If so, perhaps retrying the request will eventually return 501.</p> <p>Robot hadn't been receiving 401 few weeks ago. Auth parameters for a particular http session are set at the suite start and remain the same for the suite duration. There is practically no place where to make a mistake on robot side.</p> <p>Either way it's not a clustering issue. I would suggest moving this to the integration project and first debugging it on the robot side. </p> <p>(In reply to Peter Gubka from comment #2)<br/> &gt; Robot hadn't been receiving 401 few weeks ago. Auth parameters for a<br/> &gt; particular http session are set at the suite start and remain the same for<br/> &gt; the suite duration. There is practically no place where to make a mistake on<br/> &gt; robot side.</p> <p>Moving to restconf for now. Can this be related to <a href="https://jira.opendaylight.org/browse/AAA-119" title="Bad padding in encrypted data" class="issue-link" data-issue-key="AAA-119"><del>AAA-119</del></a>?</p> <p>(In reply to Robert Varga from comment #4)<br/> &gt; Moving to restconf for now. Can this be related to <a href="https://jira.opendaylight.org/browse/AAA-119" title="Bad padding in encrypted data" class="issue-link" data-issue-key="AAA-119"><del>AAA-119</del></a>?</p> <p>It can be related to it.</p> Duplicate AAA-119 Development External issue ID 8209 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01yan: