Updating OpenFlow group table bucket list in OpenDaylight

Question

I have a mininet (v2.2.2) network with openvswitch (v2.5.2), controlled by OpenDaylight Carbon. My application is an OpenDaylight karaf feature. The application creates a flow (for multicasts) to a group table (type=all) and adds/removes buckets as needed. To add/remove buckets, I first check if there is an existing group table:

InstanceIdentifier<Group> groupIid = InstanceIdentifier.builder(Nodes.class)
    .child(Node.class, new NodeKey(NodId))
    .augmentation(FlowCapableNode.class)
    .child(Group.class, grpKey)
    .build();
ReadOnlyTransaction roTx = dataBroker.newReadOnlyTransaction();
Future<Optional<Group>> futOptGrp = rwTx.read(LogicalDatastoreType.OPERATIONAL, groupIid);

If it doesn't find the group table, it is created (SalGroupService.addGroup()). If it does find the group table, it is updated (SalGroupService.updateGroup()).

The problem is that it takes some time after the RPC call add/updateGroup() to see the changes in the data model. Waiting for the Future<RPCResult<?>> doesn't guarantee that the data model has the same state as the device.

So, how do I read the group table and bucket list from the data model and make sure that I am indeed reading the same state as the current state of the device?

I know that

• Add/UpdateGroupInputBuilder has setTransactionUri()
• DataBroker gives transaction to read/write
• you should use transaction chaining

But I cannot figure out how to combine these. Thank you

EDIT: Or do I have to use write transactions in stead of RPC calls?

Answer 1

I dropped using RPC calls for writing flows and switched to using writes to the config datastore. It will still take some time to see the changes appear in the actual device and in the operational datastore but that is ok as long as I use the config datastore for both reads and writes.

However, I have to keep in mind that it is not guaranteed that changes to the config datastore will always make it to the actual device. My flows are not that complicated in the sense that conflicts are unlikely to happen. Still, I will probably check consistency between operational and configuration datastore.