In my ODL code, I have recently noticed that when uninstalling flows, I get unexpected behavior. The scenario goes something like this:
A bunch of flows are installed across multiple tables
I delete a flow by using the same NodeId, TableId and FlowId that I used when creating it. For reference, I use SalFlowService's addFlow and removeFlow methods.
I execute ovs-ofctl dump-flows
and notice that ALL flows on the given node and given table are deleted. For reference, the flowId I use is something like "routing-rename-src-0.0.0.0-to-123.123.123.0".
It appears to me that ODL somehow completely fails at recognizing the FlowId, and defaults to deleting all flows on the given table. No error messages are sent from OpenFlow, and no errors are logged in ODL.
The thing is, I am definitely using the same FlowId object.
Now, I am a bit confused about what could go wrong, but I have an idea, it's just that there's conflicting evidence online, and since I haven't worked on OpenFlowPlugin, I can't quite tell myself.
Flows are or tend to be posted using integers for flowIds, in the REST request paths.
In ODL code such as l2switch, flowIDs can be strings. This makes certain debugging easier to parse through.
Now, this is pretty strange. Are we using integers, or strings, or can ODL make a conversion between integer and strings by a mapping mechanism of sorts? Either way, I get unexpected behavior. Interestingly, the code I linked to does not do deletion... so maybe it's more of a hack in this case?
EDIT : I have now tried to rename my IDs as mere numbers, or as "PluginName" + "-" + number, and uninstallation still seems to fail. The problem is now that I just can't uninstall a flow rule without uninstalling the entire table with it...
EDIT 2 : This issue allowed me to understand that the flow id is not necessarily used to remove the flow. I came up with the following procedure to delete flows, in a way that doesn't cause all flows on the table to get deleted:
final RemoveFlowInputBuilder builder = new RemoveFlowInputBuilder(flow);
builder.setNode(new NodeRef(nodeId));
builder.setFlowRef(new FlowRef(flowPath));
builder.setFlowTable(new FlowTableRef(tableId));
flowIdentity.context.salFlowService.removeFlow(builder.build());
The very difference with my previous code was that I was not using a Flow object to initialize the input builder. In this form, my methods for adding and removing are identical. As long as I preserve the Flow object after adding the flow, I can delete the flow, and the tables will not be wiped.
But there is an exception. On table 0, I have installed two different table-change rules with identical actions, but different priorities. The matches are slightly different (one defines an in-port, the other doesn't). When I delete the most generic (and lowest priority) rule, the other one gets deleted also.
I don't understand why this happens. Even if I try setting the priority in the input builder, this still happens. Hrm.
As I wrote in my second edit, this post suggests that flow deletion does not work explicitly based on Id, but rather, on the fields that are defined in the input builder of the method. I haven't tested this, but I suspect if the flow reference is omitted from the builder, the defined fields will be used to delete all matching rules, which could imply deleting all flows by accident if the wrong fields are set.
Given the following code to add flows:
final AddFlowInputBuilder builder = new AddFlowInputBuilder(flow);
builder.setNode(new NodeRef(nodeId));
builder.setFlowRef(new FlowRef(flowPath));
builder.setFlowTable(new FlowTableRef(tableId));
builder.setPriority(flow.getPriority());
flowIdentity.context.salFlowService.addFlow(builder.build());
The following code to remove flows works as expected (using the SAME Flow object):
final RemoveFlowInputBuilder builder = new RemoveFlowInputBuilder(flow);
builder.setNode(new NodeRef(flowLocation.nodeIdentifier));
builder.setFlowRef(new FlowRef(flowLocation.flowPath));
builder.setFlowTable(new FlowTableRef(flowLocation.tableIdentifier));
builder.setPriority(flow.getPriority());
builder.setStrict(Boolean.TRUE);
flowIdentity.context.salFlowService.removeFlow(builder.build());
Without "strict" set to true, this can cause unexpected deletion of similar rules on the same table. I am unsure of the way flows are matched on deletion, with or without strict, but this much I can confirm.