-
Bug
-
Resolution: Done
-
None
-
unspecified
-
None
-
Operating System: All
Platform: All
-
5721
3 ODL (odl-mdsal-clustering, odl-jolokia, odl-ovsdb-openstack). Controllers were freshly
unzipped and started and the below steps were done. This is with a recent (4/12)
stable/beryllium distribution.
ODL_1=172.18.182.15
ODL_1=172.18.182.3
ODL_1=172.18.182.19
two ovs nodes A=172.18.182.7 and B=172.18.182.17, and made these two configs:
ovs-vsctl set Open_vSwitch $OVS_UUID other_config:local_ip=$OVS_SYSTEM_IP
ovs-vsctl set-manager tcp:$ODL_1:6640 tcp:$ODL_2:6640 tcp:$ODL_3:6640
A received the br-int config and netvirt pipeline, but B did not.
ovs output from A:
-------------------------
- ovs-vsctl show
ce273766-0e83-4f5f-87d7-e5014531dc60
Manager "tcp:172.18.182.19:6640"
is_connected: true
Manager "tcp:172.18.182.3:6640"
is_connected: true
Manager "tcp:172.18.182.15:6640"
is_connected: true
Bridge br-int
Controller "tcp:172.18.182.15:6653"
is_connected: true
Controller "tcp:172.18.182.3:6653"
is_connected: true
Controller "tcp:172.18.182.19:6653"
is_connected: true
fail_mode: secure
Port br-int
Interface br-int
type: internal
ovs_version: "2.0.2"
- ovs-ofctl -OOpenflow13 dump-flows br-int
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=496.032s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
cookie=0x0, duration=496.032s, table=0, n_packets=7, n_bytes=558, priority=0 actions=goto_table:20
cookie=0x0, duration=496.022s, table=20, n_packets=7, n_bytes=558, priority=0 actions=goto_table:30
cookie=0x0, duration=496.003s, table=30, n_packets=7, n_bytes=558, priority=0 actions=goto_table:40
cookie=0x0, duration=495.976s, table=40, n_packets=7, n_bytes=558, priority=0 actions=goto_table:50
cookie=0x0, duration=495.95s, table=50, n_packets=7, n_bytes=558, priority=0 actions=goto_table:60
cookie=0x0, duration=495.929s, table=60, n_packets=7, n_bytes=558, priority=0 actions=goto_table:70
cookie=0x0, duration=495.901s, table=70, n_packets=7, n_bytes=558, priority=0 actions=goto_table:80
cookie=0x0, duration=495.877s, table=80, n_packets=7, n_bytes=558, priority=0 actions=goto_table:90
cookie=0x0, duration=495.837s, table=90, n_packets=7, n_bytes=558, priority=0 actions=goto_table:100
cookie=0x0, duration=495.818s, table=100, n_packets=7, n_bytes=558, priority=0 actions=goto_table:110
cookie=0x0, duration=495.798s, table=110, n_packets=7, n_bytes=558, priority=0 actions=drop
root@jamo-mininet-ubuntu14:/home/ubuntu#
ovs output from B:
-------------------------
- ovs-vsctl show
d2f2225b-9b42-4cb7-b0d2-8e4f5f03761a
Manager "tcp:172.18.182.19:6640"
is_connected: true
Manager "tcp:172.18.182.3:6640"
is_connected: true
Manager "tcp:172.18.182.15:6640"
is_connected: true
ovs_version: "2.4.0"
on repeated attempts, the problem remained. doing a "del-manager" followed by a "set-manager" I could
see two controllers log that they were "NOT an OWNER of the device". The 3rd controller would have
this exception:
2016-04-12 23:19:19,704 | WARN | pool-37-thread-3 | OvsdbConnectionManager | 252 -
org.opendaylight.ovsdb.southbound-impl - 1.2.3.SNAPSHOT | OVSDB entity Entity{type='ovsdb',
id=/(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology/topology/topology[
]/node/node[
{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://uuid/d2f2225b-9b42-4cb7-b0d2-8e4f5f03761a}]}
was already registered for ownership
org.opendaylight.controller.md.sal.common.api.clustering.CandidateAlreadyRegisteredException: Candidate has already been
registered for Entity{type='ovsdb',
id=/(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology/topology/topology[
]/node/node[
{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://uuid/d2f2225b-9b42-4cb7-b0d2-8e4f5f03761a}]}
at
org.opendaylight.controller.cluster.datastore.entityownership.DistributedEntityOwnershipService.registerCandidate(DistributedEntityOwnershipService.java:142)[165:org.opendaylight.controller.sal-distributed-datastore:1.3.2.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.OvsdbConnectionManager.registerEntityForOwnership(OvsdbConnectionManager.java:515)[252:org.opendaylight.ovsdb.southbound-impl:1.2.3.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.OvsdbConnectionManager.connected(OvsdbConnectionManager.java:115)[252:org.opendaylight.ovsdb.southbound-impl:1.2.3.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.impl.OvsdbConnectionService$5.run(OvsdbConnectionService.java:379)[249:org.opendaylight.ovsdb.library:1.2.3.SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_77]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_77]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_77]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_77]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_77]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]
The workaround was to stop ovs, delete the /etc/openvswitch/conf.db, start ovs and set the managers
again. This time br-int was created and the netvirt pipeline showed up.