[OVSDB-138] Pipeline flows are not programmed because of failed onNodeUpdated call Created: 12/Feb/15  Updated: 19/Oct/17  Resolved: 04/May/15

Status: Resolved
Project: ovsdb
Component/s: openstack.net-virt-providers
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Sam Hague 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


External issue ID: 2707

 Description   

I see a case where the method below is called when a new openflow node connects. onNodeUpdated is called, we log it, read from the datastore and then enqueue a message to be processed later that will program the pipeline flows. What I am seeing is sometimes the enqueue doesn't happen. I don't see the error log from the onFailure path so I am assuming the optional.isPresent is true. We always get two of the onNodeUpdated callbacks per node. The nodes were just added so I don't see how the first callback doesn't have the field isPresent as true. Or I have no idea what that flag is for. But in the success case the flag is false the first time so the node is enqueued one time and everything works.

Node Update received for : KeyedInstanceIdentifier

{targetType=interface org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node, path=[org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.Nodes, org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node[key=NodeKey [_id=Uri [_value=openflow:25030657407808]]]]}

"

/**

  • Process the Node update notification. Check for Openflow node and make sure if the bridge is part of the Pipeline before
  • programming the Pipeline specific flows.
    */
    @Override
    public void onNodeUpdated(NodeUpdated nodeUpdated) {
    NodeRef ref = nodeUpdated.getNodeRef();
    InstanceIdentifier<Node> identifier = (InstanceIdentifier<Node>) ref.getValue();
    logger.debug("Node Update received for : "+identifier.toString());
    final NodeKey key = identifier.firstKeyOf(Node.class, NodeKey.class);
    final String nodeId = key.getId().getValue();
    if (key != null && key.getId().getValue().contains("openflow")) {
    InstanceIdentifierBuilder<Node> builder = ((InstanceIdentifier<Node>) ref.getValue()).builder();
    InstanceIdentifierBuilder<FlowCapableNode> augmentation = builder.augmentation(FlowCapableNode.class);
    final InstanceIdentifier<FlowCapableNode> path = augmentation.build();
    BindingTransactionChain txChain = mdsalConsumer.getDataBroker().createTransactionChain(this);
    CheckedFuture readFuture = txChain.newReadWriteTransaction().read(LogicalDatastoreType.OPERATIONAL, path);
    Futures.addCallback(readFuture, new FutureCallback<Optional<? extends DataObject>>() {
    @Override
    public void onSuccess(Optional<? extends DataObject> optional)
    Unknown macro: { if (!optional.isPresent()) { enqueue(nodeId); } }

@Override
public void onFailure(Throwable throwable)

{ logger.debug(String.format("Can't retrieve node data for node %s. Writing node data with table0.", nodeId)); enqueue(nodeId); }

});
}
}



 Comments   
Comment by Sam Hague [ 12/Feb/15 ]

This seems to happen with helium-sr2. it may only happen 1 out of 10 times or more often.

I don't think I have seen it on lithium.

Comment by Sam Hague [ 13/Feb/15 ]

There could be a race condition with InventoryManager. OVSDB looks up the node in the datastore and if not found (isPresent=false) will then program the pipeline flows. InventoryManager will add the node to the datastore so if that happens around the same time as the OVSDB node lookup the node will be found and the pipeline flows not provisioned.

Solution:
Replace the onNodeUpdated with a datachange listener for the flowCapableNode and key off it for node changes. This should be more deterministic.

Comment by Sam Hague [ 16/Feb/15 ]

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

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