[OVSDB-399] ODL does not reconcile pre-created OVS ports Created: 30/Jan/17  Updated: 19/Oct/17  Resolved: 20/Jul/17

Status: Resolved
Project: ovsdb
Component/s: Southbound.Open_vSwitch
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Tim Rozet Assignee: Unassigned
Resolution: Won't Do 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: 7707

 Description   

When connecting OVS to ODL - if ports already exist that ODL would want to create, it will fail to reconcile and result in errors. This was seen in Boron. For example, if vxlan tunnel ports already exist, I see ODL create 2 more vxlan ports, instead of using the ones that already exist:

[root@overcloud-novacompute-1 ~]# ovs-vsctl show
be5e9b0f-2a00-4b71-beae-2279c1826525
Manager "tcp:192.0.2.4:6640"
is_connected: true
Bridge br-int
Controller "tcp:192.0.2.4:6653"
is_connected: true
Controller None
fail_mode: secure
Port "tap4a993a0d-12"
Interface "tap4a993a0d-12"
Port "tune12ce5d9e46"
Interface "tune12ce5d9e46"
type: vxlan
options:

{key=flow, local_ip="11.0.0.26", remote_ip="11.0.0.21"}
Port "tun55eac6c4536"
Interface "tun55eac6c4536"
type: vxlan
options: {key=flow, local_ip="11.0.0.26", remote_ip="11.0.0.27"}
Port "tune230956df1c"
Interface "tune230956df1c"
type: vxlan
options: {key=flow, local_ip="11.0.0.26", remote_ip="11.0.0.21"}

Port "tapdf0e53b9-59"
Interface "tapdf0e53b9-59"
Port "tunad8086e8030"
Interface "tunad8086e8030"
type: vxlan
options:

{key=flow, local_ip="11.0.0.26", remote_ip="11.0.0.21"}

In another example, if I am using br-ex as my external network provider mapping. ODL usually will come up and create a patch port between br-ex and br-int. However, if that patch port already exists - ODL will error (in netvirt):
2017-01-30 13:50:19,051 | ERROR | pool-47-thread-1 | NatInterfaceStateChangeListener | 326 - org.opendaylight.netvirt.natservice-impl - 0.3.3.Boron-SR3 | Unable to process add for interface 192152954067022:br-ex-patch ,since Interface ConfigDS entry absent for the same
2017-01-30 14:15:49,096 | ERROR | pool-46-thread-1 | SubnetOpDpnManager | 317 - org.opendaylight.netvirt.vpnmanager-impl - 0.3.3.Boron-SR3 | Cannot get, portOp for port 192152954067022:br-ex-patch:flat is not available in datastore

 Comments   
Comment by Michael Vorburger [ 01/Feb/17 ]

From: Sam Hague <shague@redhat.com>
Date: Tue, Jan 31, 2017 at 4:59 PM
Subject: Re: OpenDaylight upgrading schemas of config data store YANG models - examples?

Tim can you add the karaf logs to that bug? The logs will show exceptions in models where something is inconsistent.

Comment by Tim Rozet [ 01/Feb/17 ]

(In reply to Michael Vorburger from comment #1)
> From: Sam Hague <shague@redhat.com>
> Date: Tue, Jan 31, 2017 at 4:59 PM
> Subject: Re: OpenDaylight upgrading schemas of config data store YANG models
> - examples?
>
> Tim can you add the karaf logs to that bug? The logs will show exceptions in
> models where something is inconsistent.

Sorry I don't have that setup anymore, and I don't have time to test it right now. I just filed it to track. Easy way to test is just setup ODL deployment, then stop ODL, disconnect switches, rm -rf $ODL/, copy new ODL there and start it, wait till netvirt is up, reconnect switches (ports will remain on switches from previous deployment), observe the bug

Comment by Vinh Nguyen [ 07/Jul/17 ]

With the following reproduction steps, I can reproduce this issue in Boron SR3 BUT the problem is not observed in in most recent Carbon release (as of July 6 2017)

1) Start Control and Compute node
2) Start ODL
3) Create network 1
4) Create two instances VM1 on control node and VM2 on compute node for network 1
5) Stop ODL
6) Disconnect OVS, (ovs-vsctl del-manager on control and compute nodes)

7) rm ODL directory
8) Install and start fresh ODL setup
9) create network 2
10) Create two instances VM3 on control node and VM4 on compute node for network 2

11) Observe, only with BORON release, the two tunnel ports for the same vxlan tunnel between control and compute node. The problem is not observed if Carbon release is used

Comment by Sam Hague [ 20/Jul/17 ]

This works in carbon and boron will not be receiving updates.

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