[OVSDB-156] Clustering: Errors if controller started after OVS configured with set-manager Created: 17/May/15  Updated: 14/Jan/19  Resolved: 12/Jun/15

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

Type: Bug
Reporter: Keith Burns Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
is blocked by OPNFLWPLUG-442 redesign ofp inventory looses switche... Resolved
External issue ID: 3238
Priority: High

 Description   

If I have an OVS instance with "set-manager" set to point to the controller
ovs-vsctl set-manager tcp:<ip>:6640

THEN I remove journal etc (persisted data) and start controller I see following over and over again:
http://pastebin.com/TcwBS9dr

If I reverse that order:
(start ODL with cleaned out journal etc, wait until initialized)
THEN
set-manager

I do not.

What I see instead is over and over:
2015-05-17 09:32:31,512 | WARN | ds-oper-thread-0 | TransactionProxy | 179 - org.opendaylight.controller.sal-distributed-datastore - 1.2.0.SNAPSHOT | Failed to acquire operation permit for transaction member-1-txn-85

Every 5 seconds.

Note I haven't done anything at all except load my features in either case. There is no config other than a bridge in either case, and NO PERSISTED STATE in any case.

 

 Comments   
Comment by Ed Warnicke [ 17/May/15 ]

I think that this might be fixed by this:

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

Basically, you are telling karaf to start sfc-ovs before ovsdb-southbound.

This patch tells karaf to start ovsdb-southbound before sfc-ovs.

I can't quite explain everything I see in the logs from this, but it has a pretty good chance of fixing the issue. Would someone please test it?

Comment by Moiz Raja [ 18/May/15 ]

Patch for the "Failed to acquire operation permit" issue

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

Comment by Tony Tkacik [ 19/May/15 ]

Seems as duplicate of OPNFLWPLUG-442 or as Moiz pointed out related to OPNFLWPLUG-442.

Comment by Keith Burns [ 22/May/15 ]

I still have the same issue.

Note we have EVERY SFC feature loaded and Ed had a patch https://git.opendaylight.org/gerrit/#/c/20619/ to address it. When I tested this on Tuesday the patch didn't resolve the issue.

Comment by Keith Burns [ 24/May/15 ]

They key here is if there is an OVS switch configured and has set-manager configured, this happens every time you bring the controller up..

This is a big problem for us with DevStack.

Comment by Tony Tkacik [ 24/May/15 ]

Known facts:

  • OVSDB stores remote-ids on OVS instances (instance-identifier to datastore)
  • Journal is deleted-

Theory:

  • OVS reconnects to controller after journal is deleted, OVSDB learns state from
    Device along with remote-id there from previous session - this remote ID contains
    instance-identifier to datastore. OVSDB southbound tries to update data store,
    but does not expect it wiped (which happened when journal was created).

So this could be OVSDB southbound bug - when remote-id is present before anything was configured to controller.

@eaw: could it be this?

Comment by Keith Burns [ 26/May/15 ]

Tony, you maybe onto something:

When I do:
sudo ovs-vsctl del-manager
sudo ovs-vsctl set-manager tcp:192.168.50.1:6640

I get endless:
http://pastebin.com/xe9EiXnW

Comment by Tony Tkacik [ 26/May/15 ]

Seems this is ovsdb related somehow rather than clustering or md-sal.
Moving it back to ovsdb so ovsdb folks are aware of that.

Comment by Ed Warnicke [ 26/May/15 ]

I believe this is related to OVSDB-157 and OVSDB-158

Comment by Ed Warnicke [ 31/May/15 ]

Should be fixed by
https://git.opendaylight.org/gerrit/#/c/21484/

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