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/OPNFLWPLUG-748 OpenFlowPlugin <p>This issue is tracked here:</p> <p><a href="https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/</a></p> <p>Similar issue was resolved for He plugin:</p> <p><a href="https://bugs.opendaylight.org/show_bug.cgi?id=6058" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=6058</a></p> <p>BR/Luis</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-748

Switch is still seen after owner goes down in non OFHA scenario

Bug Resolved Done Luis Gomez Luis Gomez Thu, 18 Aug 2016 02:13:14 +0000 Mon, 27 Sep 2021 09:01:52 +0000 Tue, 16 May 2017 01:54:34 +0000 General 0 7 <p>Just wondering / asking is FMR reconciliation design dependent ?</p> <p>(In reply to Jozef Bacigal from comment #1)<br/> &gt; Just wondering / asking is FMR reconciliation design dependent ?</p> <p>What do you mean by design-dependent? whether its linked to He/Li plugin design ? nopes . the moment we get a node connected we check if i am the master and then push the configuration.While i debug i can see it happening , so whether its an heisen i am not sure <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/biggrin.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>the issue with 6058 was that the EOS was having a stale entry, so reconciliation wasnot getting triggered since the DTCL was not fired after a node disconnect. We need to check if that is the case</p> <p>I saw that there are a lot of NPEs in logs. It was because DeviceMasterShipManager was created after we was registering forwarders in FRM, so there was possibility, that DeviceMasterShipManager will be null when we received DataTreeChange event and we wanted to check if node is owner or not.</p> <p>Here is link to Gerrit: <a href="https://git.opendaylight.org/gerrit/#/c/45877" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/45877</a></p> <p>My observation on this bug is that controller does not support restart of the device owner when switches only connect to the owner. Entity owner, inventory and topology API freeze and never leave this state after owner goes down.</p> <p>&gt; This issue is tracked here:</p> <p>I see a reconciliation suite passing <span class="error">&#91;0&#93;</span>. Where should are look more specifically?</p> <p><span class="error">&#91;0&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/237/archives/log.html.gz#s1-s1" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/237/archives/log.html.gz#s1-s1</a></p> <p>Same on Carbon <span class="error">&#91;1&#93;</span>.</p> <p><span class="error">&#91;1&#93;</span> <a href="https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/176/archives/log.html.gz#s1-s1" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/176/archives/log.html.gz#s1-s1</a></p> <p>The red tests, right? in particular the Check No Network and Verify Flows in Switch TCs.</p> <p>Muthu,</p> <p>Can you check this?</p> <p>Abhijit</p> <p>So I think this bug is related to the cluster issue exposed lately of instances not connecting to switch do not get proper notification for switch events. This is a miss in singleton API but I think there is some decision to workaround the problem in openflowplugin.</p> <p>Can you confirm if this still exists? The current jenkins seems to be passing: <br/> <a href="https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/</a></p> <p>Assigning to Luis for confirmation.</p> <p>This bug is fixed through <a href="https://bugs.opendaylight.org/show_bug.cgi?id=7736" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7736</a></p> <p>Reopen for Carbon, we can still see alien switch in cluster when owner (only one connecting to switch) goes down:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/219/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/219/archives/log.html.gz</a></p> <p>New example for Carbon where switch is still seen after owner goes down.</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/229/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/229/archives/log.html.gz</a></p> <p>Luis, to find some answers I have one quick questions. </p> <p>What actually means kill controller? You close karaf instance or just disable the network connection ? Is there only one controller ?</p> <p>We kill tha karaf process.</p> <p>This is how to reproduce manually:</p> <ul class="alternate" type="square"> <li>Connect switch to 1 node out of the 3 that conforms the cluster.</li> <li>Kill the karaf process of that node.</li> <li>Check switch operational info (inv &amp; topo) is still available where there is no switch connected to cluster anymore.</li> <li>Disconnect switch from killed node.</li> <li>Start killed node.</li> <li>Check switch operational info (inv &amp; topo) is still available where there is no switch connected to cluster anymore.</li> </ul> <p>BR/Luis</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/56230/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/56230/</a></p> <p>Patch looks good.</p> <p>Rising to blocker as this works in Boron.</p> <p>Patch <a href="https://git.opendaylight.org/gerrit/#/c/57090/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/57090/</a> was successfully merged. Can we mark this bug as fixed and resolved?</p> <p>Yes we can close this.</p> Duplicate OPNFLWPLUG-757 Development External issue ID 6459 External issue URL Rank 0|i0332f: