[OPNFLWPLUG-853] Only 1 cluster instance is able to push table miss flow after initial switch connection Created: 10/Feb/17  Updated: 27/Sep/21  Resolved: 14/Apr/17

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Luis Gomez Assignee: Miroslav Macko
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 7770

 Description   

This is tracked here:

https://jenkins.opendaylight.org/releng/view/CSIT-3node/job/openflowplugin-csit-3node-clustering-only-boron/

To reproduce:

1) Set up 3 cluster node with openflow and table miss features enabled.
2) Connect OVS switch to 1st node: sudo mn --controller 'remote,ip=192.168.0.101,port=6633' --topo tree,1
3) check table miss flow in mininet: dpctl dump-flows
4) stop and start mininet to 2nd node: sudo mn --controller 'remote,ip=192.168.0.102,port=6633' --topo tree,1
5) check table miss flow in mininet: dpctl dump-flows
6) Repeat 4) & 5) with 3rd node in the cluster.

After the above steps you will realize that only one of the instances (normally the first that is master) is able to push the table miss flow.

BR/Luis

 Comments   
Comment by Vratko Polak [ 10/Feb/17 ]

> This is tracked here

The recent run only has two failures in suite "030 Cluster Sync Problems".
Which suite does tests the "each mininet connects to different member" scenario?

[0] https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-clustering-only-boron/944/archives/log.html.gz#s1-s6

Comment by Vratko Polak [ 10/Feb/17 ]

> recent run only has two failures

Carbon has 1 less [1].

[1] https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-clustering-only-carbon/478/archives/log.html.gz#s1-s6

Comment by Luis Gomez [ 10/Feb/17 ]

There is no spceific TC to catch this bug, it can happen here are there. What matters is that this issue is 1 min to reproduce with steps above and I can add a TC just to check when it gets resolved.

Comment by Miroslav Macko [ 24/Feb/17 ]

https://git.opendaylight.org/gerrit/#/c/52115/

Comment by Miroslav Macko [ 06/Mar/17 ]

Hello Luis,

Could you please test this patch?

I have tested it locally. It works.

Thanks,
Miro

Comment by Luis Gomez [ 06/Mar/17 ]

We do have automated test for this but the infra is no good since the weekend, I will try in the sandbox and +1 your patch if it works there.

Comment by Luis Gomez [ 08/Mar/17 ]

By looking at this run, it seems fixed:

https://logs.opendaylight.org/sandbox/jenkins091/openflowplugin-csit-3node-clustering-only-carbon/6/archives/log.html.gz

But looking at the failure, have you rebased you patch lately?

Comment by Miroslav Macko [ 08/Mar/17 ]

Thanks Luis,

I have rebased it now.

Miro

Comment by Jozef Bacigal [ 10/Mar/17 ]

Luis how this fix is running? It can be merged ?

Comment by Luis Gomez [ 13/Mar/17 ]

It fixes the issue but there is something weird with the switch disconnect test, this patch seems to revert to old cluster behavior of instances disconnected from switch showing as candidate in entity owner:

https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-3node-clustering-only-carbon/551/archives/log.html.gz

Comment by Luis Gomez [ 13/Mar/17 ]

Thats why I thought a rebase was needed but i still see the change in the switch disconnect test after rebasing.

Comment by Luis Gomez [ 17/Mar/17 ]

I think Anil found the reason for the behavior change and -1 the patch.

Comment by Miroslav Macko [ 20/Mar/17 ]

Hi Luis,

I have pushed the new patch without the ClusterSingletonService.

https://git.opendaylight.org/gerrit/#/c/53557

Could you please test it?

Thank you,
Miro

Comment by Luis Gomez [ 14/Apr/17 ]

This is fixed now.

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