[NETCONF-398] Carbon: odl respond with http status 401 in various suites Created: 11/Apr/17  Updated: 15/Mar/19  Resolved: 18/Apr/17

Status: Resolved
Project: netconf
Component/s: restconf-nb
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Peter Gubka Assignee: Jakub Toth
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Duplicate
duplicates AAA-119 Bad padding in encrypted data Verified
External issue ID: 8209

 Description   

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.
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.

Job: https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-only-carbon/626/

Suite: Rpc Provider Partition And Heal

  • 2 nodes have rpc registered, the 3rd one no
  • the one without rpc is isolated and we expect status code 501 when rpc called, but 401 is returned

Suite: Action Provider Partition And Heal
A node with routed rpc is isolated. The rpc is then called on that node and status 200 is expected. 401 is returned.

Suite: Partition And Heal (Clustering Singleton)
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.

This may not be the single problem, but all is related to node isolation process.

 Comments   
Comment by Tom Pantelis [ 11/Apr/17 ]

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.

Comment by Peter Gubka [ 12/Apr/17 ]

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.

Comment by Tom Pantelis [ 12/Apr/17 ]

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.

(In reply to Peter Gubka from comment #2)
> 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.

Comment by Robert Varga [ 12/Apr/17 ]

Moving to restconf for now. Can this be related to AAA-119?

Comment by Peter Gubka [ 13/Apr/17 ]

(In reply to Robert Varga from comment #4)
> Moving to restconf for now. Can this be related to AAA-119?

It can be related to it.

Generated at Wed Feb 07 20:14:55 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.