Operating System: All
Platform: All

The reason that the flows are missing is because the operational data store does not reflect the state of the vSwitch – the vSwitch has 6 ports, but the operational data store has less than 6 (and sometimes even no ports).

Further investigation suggests that the controller is getting node removed/added events interleaved with node connector updates, which causes the operational data store to get out of sync (e.g. add port 1, add port 2, node removed, node updated, add port 3, add port 4... results in the node missing ports 1 and 2). It was believed that the node removed/added events were the result of changing the vSwitch from 1.0 to 1.3 operation using ovs-vsctl (done in python script used for demo).

We're testing a solution that involves starting the vSwitch in 1.3 operation, using a patched version of mininet described here:

https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Create_System_Test_Environment#Mininet_2.1.0

Testing so far has shown success 10/10 runs. The tests would typically fail at least once in doing this.

We will close this bug and re-open one against the openflowplugin.

To recreate the problem:

1) Use the two node setup (two VMs, each with vSwitch) described here:

https://wiki.opendaylight.org/view/Group_Policy:Building_and_Running

2) Start the group based policy feature with REST:
opendaylight-user@root>feature:install odl-restconf odl-groupbasedpolicy-ofoverlay

3) Run the rest of the demo described in the link in #1

4) The failure case will have node-connector's missing on the first switch. In other words, the following URL:

http://localhost:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:1

will show less than 6 node connectors