[CONTROLLER-1452] 3 # cluster : Pre-provision is not happening when the switch is connected with follower node Created: 24/Nov/15  Updated: 19/Oct/17  Resolved: 27/Jan/16

Status: Resolved
Project: controller
Component/s: clustering
Affects Version/s: Lithium
Fix Version/s: None

Type: Bug
Reporter: Anpukarasi Muthukumaran Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: Text File karaf.log    
Issue Links:
Duplicate
duplicates CONTROLLER-1475 Supervisor Strategy caught unexpected... Resolved
is duplicated by CONTROLLER-1453 3 # cluster : Pre-provision is not ha... Resolved
External issue ID: 4664
Priority: Highest

 Description   

I found that pre-provision is not happening when the switch gets connected with follower node. But at the same time, when the switch is connected with leader node, switch gets all the flows.

I am seeing this issue in 3 # node cluster and build version is distribution-karaf-0.3.3-Lithium-SR3.zip

I tested this in following cases;

case 1: configure flows in leader node
-------------------------------------------

a. connect the switch in leader node – pre-provision is working
b. Connect the switch in follower node - pre-provision is not working

case 2: configure flows in either of follower node
---------------------------------------------------

a. Connect the switch in leader node – pre-provision is working
b. connect the switch in either of the follower node – pre-provision is not working.

here with I am enclosing
opendaylight-inventory-nodes-operational-follower-node (open it in notepad / winword)
opendaylight-inventory-nodes-config-follower2 (can open it in notepad /winword)
follower2 --(pcap file, open it in wireshark)
karaf.log (open it in notepad)

 Comments   
Comment by Anpukarasi Muthukumaran [ 24/Nov/15 ]

Attachment karaf.log has been added with description: karaf.log

Comment by Moiz Raja [ 08/Dec/15 ]

Is this just a dup of 4665?

Comment by Robert Varga [ 19/Jan/16 ]

Is trhis reproducible in Be?

I think we fixed this:
2015-11-23 00:50:23,754 | WARN | ult-dispatcher-3 | ShardManager | 207 -
org.opendaylight.controller.sal-distributed-datastore - 1.2.3.Lithium-SR3 | Supervisor
Strategy caught unexpected exception - resuming
org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaValidationFailedExcepti
n: Child [] is not present in schema tree.
at
org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModificationC
rsor.resolveChildModification(InMemoryDataTreeModificationCursor.java:55
[90:org.opendaylight.yangtools.yang-data-impl:0.7.3.Lithium-SR3]
at
org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModificationC
rsor.write(InMemoryDataTreeModificationCursor.java:112
[90:org.opendaylight.yangtools.yang-data-impl:0.7.3.Lithium-SR3]
at
org.opendaylight.yangtools.yang.data.api.schema.tree.DataTreeCandidates.applyToPar
ntCursor(DataTreeCandidates.java:99)[80:org.opendaylight.yangtools.yang-data
api:0.7.3.Lithium-SR3]
at
org.opendaylight.yangtools.yang.data.api.schema.tree.DataTreeCandidates.applyToRoo
Cursor(DataTreeCandidates.java:116)[80:org.opendaylight.yangtools.yang-data
api:0.7.3.Lithium-SR3]
atorg.opendaylight.yangtools.yang.data.api.schema.tree.DataTreeCandidates.applyToCur
or(DataTreeCandidates.java:48)[80:org.opendaylight.yangtools.yang-data
api:0.7.3.Lithium-SR3]
at
org.opendaylight.yangtools.yang.data.api.schema.tree.DataTreeCandidates.applyToMod
fication(DataTreeCandidates.java:36)[80:org.opendaylight.yangtools.yang-data
api:0.7.3.Lithium-SR3]
at
org.opendaylight.controller.cluster.datastore.ShardDataTree.applyForeignCandidate(Sha
dDataTree.java:178)[207:org.opendaylight.controller.sal-distributed
datastore:1.2.3.Lithium-SR3]
at

Comment by Colin Dixon [ 19/Jan/16 ]

Robert says that there are failures to replicate data because of empty data items in the logs on BUG4665, but he thinks that's fixed in Berylilum.

He also says that he sees empty child issues that are fixed in Beryllium, also OpenFlow plugin connection and disconnection.

See if this can be reproduced in Beryllium. Also, confirm that the relevant things have been fixed on stable/lithium.

Comment by Anil Vishnoi [ 19/Jan/16 ]

I still see it in Beryllium release, i am investigating it and will provide more details on how to recreate it.

Comment by Anil Vishnoi [ 20/Jan/16 ]

Although the exception i am seeing in my environment says

Supervisor Strategy caught unexpected exception - resuming

but it's happening because of NPE, while doing cluster data replication. I will open another bug for that.

Comment by Ryan Goulding [ 26/Jan/16 ]

The current theory is that this is caused by Bug-5019. Anil, can you confirm?

Comment by Anil Vishnoi [ 26/Jan/16 ]

The main issue is happening probably because of some issue in RPC routing. If switch connects to follower node then RPC for the switch will be registered on the follower. In this case RPC needs to be routed to follower from leader, and i think there is some issue there. I am not entirely sure if "Supervisor
Strategy caught unexpected exception" - CONTROLLER-1475 can impact this behavior. If it can, i can test it in my environment, but i think all the related patch for 5019 are not merged yet? I will try to build controller, yangtools locally and test it, if we want to verify it before merging the relevant patches.

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