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/AAA-130 aaa <p>Currently we are thoroughly testing ODL clustering. The common scenario is that we isolate one node, verify some state we are expecting, verify some behavior we are expecting, etc. Then we join isolated node to back to cluster and again verify some state, etc.</p> <p>The problem is, that after partitioning or healing the cluster, AAA seems not to work correctly. Sometimes we get 401 response to our HTTP requests, sometimes we don't get any answer at all. This happens on isolated node but also on non-isolated nodes. </p> <p>We don't have debug logs for AAA or for RESTCONF on during our tests. I will try to replicate this locally and update the bug with relevant logs.</p> <p>Operating System: All<br/> Platform: All</p> AAA-130

AAA problems during partitioning and healing cluster

Bug Resolved Won't Do Ryan Goulding Jakub Morvay Fri, 12 May 2017 13:15:08 +0000 Thu, 21 Mar 2019 11:56:48 +0000 Wed, 7 Feb 2018 18:51:52 +0000 General 0 2 <p>&gt; we don't get any answer at all<br/> &gt; join isolated node to back to cluster</p> <p>Not only then. I see one case <span class="error">&#91;0&#93;</span> when timeout happens when isolating one member and querying one of the other two, and one case <span class="error">&#91;1&#93;</span> when timeout happens after graceful leader movement.<br/> Both cases use tell-based protocol (so the failure is unlikely to be caused by AskTimeoutException). One affects a module-based shard, the other one affects a prefix-based shard, so this is unlikely to matter.</p> <p>The only suspicious thing is that this happens when a shard leader moves, and the failure is always on the third member (not the old or the new leader).</p> <p><span class="error">&#91;0&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/673/archives/log.html.gz#s1-s44-t3-k2-k5-k1-k2-k1-k2-k1-k6-k2-k1-k2-k1-k1-k3-k3-k1" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/673/archives/log.html.gz#s1-s44-t3-k2-k5-k1-k2-k1-k2-k1-k6-k2-k1-k2-k1-k1-k3-k3-k1</a><br/> <span class="error">&#91;1&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/676/archives/log.html.gz#s1-s60-t1-k2-k12-k1-k1-k1-k6-k2-k1-k2-k1-k1-k3-k3-k1" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/676/archives/log.html.gz#s1-s60-t1-k2-k12-k1-k1-k1-k6-k2-k1-k2-k1-k1-k3-k3-k1</a></p> <p>Note that the URI which fails is /restconf/modules. I have prepared a test change to skip this check, we will see if this repeats on jolokia URI (which we need to access in order to detect the new leader).</p> <p>No failures are seen in CSIT anymore. Some were fixed, other are avoided by the suite not performing specific checks. Lowering severity to Minor, we would need a specialized suite to determine which requests are not working right during isolation scenario.</p> <p>This is expected;  Authorization requires access to MD-SAL.  During isolation, that is not possible.  Closing since it functions as designed.</p> <p>Functions as designed.</p> Development External issue ID 8432 External issue URL Rank 0|i024a7: