[OVSDB-48] precondition in getProvider failing Created: 31/Jul/14  Updated: 19/Oct/17  Resolved: 23/Sep/14

Status: Resolved
Project: ovsdb
Component/s: Neutron
Affects Version/s: unspecified
Fix Version/s: None

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

Operating System: Mac OS
Platform: PC

Issue Links:
Duplicate
is duplicated by OVSDB-52 Preconditions fails for Openflow node... Resolved
External issue ID: 1461

 Description   

I am running ODL with Openstack and seeing lots of the following exceptions
on the OSGi console.

2014-07-31 15:56:34.561 UTC [md-sal-binding-notification-85] ERROR o.o.c.sal.binding.impl.NotifyTask - Unhandled exception thrown by listener: org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter$$Broker$ListenerInvoker@6cc45b37
java.lang.IllegalArgumentException: null
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:76) ~[na:na]
at org.opendaylight.ovsdb.openstack.netvirt.impl.ProviderNetworkManagerImpl.getProvider(ProviderNetworkManagerImpl.java:40) ~[na:na]
at org.opendaylight.ovsdb.openstack.netvirt.SouthboundHandler.notifyNode(SouthboundHandler.java:335) ~[na:na]
at org.opendaylight.controller.switchmanager.internal.SwitchManager.notifyNode(SwitchManager.java:1827) ~[na:na]
at org.opendaylight.controller.switchmanager.internal.SwitchManager.updateNode(SwitchManager.java:1141) ~[na:na]
at org.opendaylight.controller.switchmanager.internal.SwitchManager.updateNode(SwitchManager.java:1153) ~[na:na]
at org.opendaylight.controller.sal.implementation.internal.Inventory.updateNode(Inventory.java:115) ~[na:na]
at org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter.publishNodeUpdate(InventoryAndReadAdapter.java:728) ~[na:na]
at org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter.onNodeUpdated(InventoryAndReadAdapter.java:463) ~[na:na]
at org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter$$Broker$ListenerInvoker.onNotification(InventoryAndReadAdapter$$Broker$ListenerInvoker.java) ~[na:na]
at org.opendaylight.controller.sal.binding.impl.AbstractNotificationListenerRegistration.notify(AbstractNotificationListenerRegistration.java:38) ~[na:na]
at org.opendaylight.controller.sal.binding.impl.NotifyTask.run(NotifyTask.java:42) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_55]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_55]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_55]
2014-07-31 15:56:34.856 UTC [nioEventLoopGroup-11-2] WARN o.o.o.p.i.c.ResponseExpectedRpcListener - Request for RpcResultKey [xid=7, outputClazz=org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.protocol.rev130731.BarrierOutput] did not receive a response

 Comments   
Comment by Dave Tucker [ 05/Aug/14 ]

To add some context...

getProvider is being called by initializeOFFlowRules which passes an OpenFlow Node ID to the ProviderNetworkManager. This code path is actually redundant as it calls initializeFlowRules which is already called by prepareNode.

The ProviderNetworkManager expects an OVSDB node ID as it manages a provider per OVS instance. The fix in this case is to either pass in an OVSDB node ID or to remove this code path completely

Comment by Madhu Venugopal [ 14/Aug/14 ]

Well... This is a bug that got introduced due to the reason per-node Provider selection. And the Provider is selected based on the capability of a given OVS node and configuration.

Having said that, if Openflow node is passed in this method, it fails because of the strict check on OVS node.

The better fix is to expand this method to tolerate both OVS and OF node and identify a provider for it.

In case of Openflow node, it is straight forward indeed. We can explicitely check if the node is an OF1.0 or OF1.3 node and hence we can choose the appropriate Provider.

Comment by Dave Tucker [ 23/Sep/14 ]

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

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