Operating System: All
Platform: All

I hope we have a way to guarantee order when things are sent to the same switch, otherwise this seems like a required enhancement.

So, your problem is basically that you are trying to achieve some sort of synchronization when writing to config datastore and then sending RPC. This is not correct.

If you want to maintain order between these operations, you can use only config datastore (and FRS), but as you are sending packet out, this is not possible, so another option is to use only RPCs and chain resulting futures, or implement DataTreeChangeListener on operational datastore and wait till statistics write changes in config to operational and then send RPC sending packet out.

1st option example:
1. Call SalFlowService#addFlow with inbound flow as input and store returned future
2. Transform this future with asyncFunction and return another call to SalFlowService#addFlow with outbound flow as input and store returned future
3. Transform this future with asyncFunction and return call to PacketProcessingService#transmitPacket (assuming that this method returns future, but I am not really sure)

These steps guarantees that these operations will be sent to device in specified order, but downside is that nothing will be written to config datastore.

2nd option example:
Create implementation of DataTreeChangeListener (or better ClusterDataTreeChangeListener) on operational datastore. Then check if your flows was succesfully written to operational and only then call PacketProcessingService#transmitPacket.

I cannot imagine any other option, because when writing to config and then sending RPC, nothing can guarantee that RPC will not be send before FRM/FRS will start syncing flows with device and operational DS, so not even correct sending of barrier will help here.

(In reply to Tomas Slusny from comment #2)
> So, your problem is basically that you are trying to achieve some sort of
> synchronization when writing to config datastore and then sending RPC. This
> is not correct.
>
> If you want to maintain order between these operations, you can use only
> config datastore (and FRS), but as you are sending packet out, this is not
> possible, so another option is to use only RPCs and chain resulting futures,
> or implement DataTreeChangeListener on operational datastore and wait till
> statistics write changes in config to operational and then send RPC sending
> packet out.
>
> 1st option example:
> 1. Call SalFlowService#addFlow with inbound flow as input and store
> returned future
> 2. Transform this future with asyncFunction and return another call to
> SalFlowService#addFlow with outbound flow as input and store returned future
> 3. Transform this future with asyncFunction and return call to
> PacketProcessingService#transmitPacket (assuming that this method returns
> future, but I am not really sure)
>
> These steps guarantees that these operations will be sent to device in
> specified order, but downside is that nothing will be written to config
> datastore.
>
> 2nd option example:
> Create implementation of DataTreeChangeListener (or better
> ClusterDataTreeChangeListener) on operational datastore. Then check if your
> flows was succesfully written to operational and only then call
> PacketProcessingService#transmitPacket.
>
> I cannot imagine any other option, because when writing to config and then
> sending RPC, nothing can guarantee that RPC will not be send before FRM/FRS
> will start syncing flows with device and operational DS, so not even correct
> sending of barrier will help here.

Tomas, thanks for the answer.
It seems you only referred to the flow_mod+packet_out dependency.

How about group_mod+flow_mod for FRM?
These both go through DS, and can be synchronized, Anil mentioned this is a bug if it doesn't work.
We cannot move to FRS at this time just for this, as it has many other side effects. Maybe in Nitrogen but we need some fix for Carbon.

Anil, we added a hack in NetVirt to get around this issue that uses barriers to force syncing the order.

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

Patch https://git.opendaylight.org/gerrit/#/c/56786/ was successfully merged. Can we mark this bug as fixed and resolved?

@Sam, cool, i believe that's the only way to resolve the packet_out + flow ordering issue. Alternate approach is to write flow to data store, wait for it to show up in the operational data store and then send out the packet_out, which probably will introduce unacceptable latency.

There was another issue of group+flow ordering that is something we can address in FRM. I will use this bug to track that. Given that your issue is has workaround solution, i am reducing the critical to critical. If you think group+flow issue is blocking, please change the priority to blocker.

Moved to Hema from Anil.

Any luck on this Hema?

Hematg Please let me know if you are planning to work on this bug, else i will more it unassigned pool.

Hematg any update on this ?

Arunprakash is currently working on fixing FRM, so that flow and groups can be program as per their inter-dependency. Once that is implemented i believe this enhancement is not required.

Arunprakash please link the Jira ticket for FRM changes to this ticket.

Above bug will be fixed through OPNFLWPLUG-991. Please see 991 for update on this issue.