Just wondering / asking is FMR reconciliation design dependent ?
(In reply to Jozef Bacigal from comment #1)
> Just wondering / asking is FMR reconciliation design dependent ?
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 
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
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.
Here is link to Gerrit: https://git.opendaylight.org/gerrit/#/c/45877
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.
> This issue is tracked here:
I see a reconciliation suite passing [0]. Where should are look more specifically?
Same on Carbon [1].
The red tests, right? in particular the Check No Network and Verify Flows in Switch TCs.
Muthu,
Can you check this?
Abhijit
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.
Can you confirm if this still exists? The current jenkins seems to be passing:
https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-boron/
Assigning to Luis for confirmation.
This bug is fixed through https://bugs.opendaylight.org/show_bug.cgi?id=7736
Reopen for Carbon, we can still see alien switch in cluster when owner (only one connecting to switch) goes down:
New example for Carbon where switch is still seen after owner goes down.
Luis, to find some answers I have one quick questions.
What actually means kill controller? You close karaf instance or just disable the network connection ? Is there only one controller ?
We kill tha karaf process.
This is how to reproduce manually:
- Connect switch to 1 node out of the 3 that conforms the cluster.
- Kill the karaf process of that node.
- Check switch operational info (inv & topo) is still available where there is no switch connected to cluster anymore.
- Disconnect switch from killed node.
- Start killed node.
- Check switch operational info (inv & topo) is still available where there is no switch connected to cluster anymore.
BR/Luis
Patch looks good.
Rising to blocker as this works in Boron.
Patch https://git.opendaylight.org/gerrit/#/c/57090/ was successfully merged. Can we mark this bug as fixed and resolved?
Yes we can close this.