Operating System: All
Platform: All

I hit this by repeating these steps several times:

1) create bridge in config
2) connect ovs (vsctl set-manager)
3) delete bridge in config
4) disconnect ovs (vsctl del-manager)

The first few iterations did not seem to have trouble, but then the IAE
was seen and now it seems we cannot connect an ovs instance to the plugin.

PUT sent to:
http://CONTROLLER-IP:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2F{{HYPERVISOR-NODE-ID}}%2Fbridge%2Fbrtest

with this data:

{
"network-topology:node": [
{
"node-id": "ovsdb://HYPERVISOR-NODE-ID/bridge/brtest",
"ovsdb:bridge-name": "brtest",
"ovsdb:datapath-id": "00:00:b2:bf:48:25:f2:4b",
"ovsdb:protocol-entry": [

],
"ovsdb:controller-entry": [
{
"target": "tcp:CONTROLLER-IP:6633"
}
],
"ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://{{HYPERVISOR-NODE-ID}}']"
}
]
}

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

Jamo, what features are loaded?

(In reply to Sam Hague from comment #3)
> Jamo, what features are loaded?

just odl-ovsdb-southbound-impl-rest

lithium: https://git.opendaylight.org/gerrit/#/c/32123/
master: https://git.opendaylight.org/gerrit/#/c/29017/2

this is still there. I am pushing a system test to let us see it in CSIT:
https://git.opendaylight.org/gerrit/#/c/33316/

but, the basic steps in comment #1 are all we need, except that I first
connect OVS, then check operational so I can know the UUID that it will
use. Then I disconnect and follow steps 1-4.

Robert Varga suspects this is a bug in OVSDB: https://lists.opendaylight.org/pipermail/controller-dev/2016-January/011309.html

"It does look like a lifecycle issue with manager-entry (which is a list). According to the message, you are attempting to delete an item in the list, but the list itself does not exist – probably deleted asynchronously by another process, such as restconf or some other part of OVSDB which does not observe the same event causality (e.g. a TransactionChain instance) as OvsdbNodeRemoveCommand."

I'm wondering if this could be caused by the ownership change handling: in OvsdbConnectionManager::handleOwnershipChanged(), if the instance is null and the entity has no owner, we forcefully clean up the operational data without going through the transaction invoker. If there's an OvsdbNodeRemoveCommand still in the invoker's queue, the clean-up will go through first, leaving the queued command dangling...

The smoking gun is the "has no owner, cleaning up the operational data store" line right before the transaction failure, just after the "Cleaning up the operational data store" line which indicates the start of an invoker-driven transaction.

https://git.opendaylight.org/gerrit/33554

https://git.opendaylight.org/gerrit/33556
https://git.opendaylight.org/gerrit/33554

CSIT shows that this Exception is no longer there. There is still a failure
in the test case because the bridge in config store is not configured via southbound when the ovs connects. I will open a new bug for that, if needed.