Hi Jamo and Alon, I posted reply to bug 8025 but I think I should also send it here.
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. So this leads me to conclusion that this is not OpenFlowPlugin bug and as Jozef said, it should be solved in downstream project. But correct me if I am wrong. Regards, Tomas Slusny ________________________________________ Od: Jozef Bacigál <[email protected]> Odoslané: 21. marca 2017 18:52 Komu: Jamo Luhrsen; N Vivekanandan; Kochba, Alon; [email protected]; Anil Vishnoi Kópia: [email protected] Predmet: Re: [openflowplugin-dev] Bug 8025 - missing method to use barrier when installing rules and giving packet_out I am not sure that in this phase of carbon release we manage or be able to create some API/logic to solve those two cases. As I mentioned: (a.) can be solved with using FRS and configDS (b.) I am not sure if plugin is the right place to solve this - my opinion is that it should be solved in downstream project: the flow-mods sender Jozef ________________________________________ Od: Jamo Luhrsen <[email protected]> Odoslané: 21. marca 2017 18:06 Komu: N Vivekanandan; Kochba, Alon; Jozef Bacigál; [email protected]; Anil Vishnoi Kópia: [email protected] Predmet: Re: [openflowplugin-dev] Bug 8025 - missing method to use barrier when installing rules and giving packet_out Thanks Anil, Thank Vivek. Hopefully we can get a solution in place soon, but in the meantime does anyone object to making this a higher priority bug? Having confidence that these races are fixed is important. They could become more prevalent in a busy/stressed environment compared to what we have in our upstream CSIT which still hits them daily. JamO On 03/21/2017 09:50 AM, N Vivekanandan wrote: > To'ed Anil > > We are using FRM and so as we discussed in NetVirt meeting, if we could get > the order of > > a. Group followed by Flows > b. Flows followed by PacketOut's that will use such Flows > > sorted out in FRM transparent to NetVirt, that would be great. > > You can see in the link below that Group 150003 is available in the group, > but Flows using that group should be available in Table 20, Table 21 and > Table 36. You can see from the link that Table 20, Table 21 does not have > the flow using that group but only Table 36 has it: > > https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-carbon/420/archives/log.html.gz#s1-s4-t15-k9-k1-k2-k1-k15-k4 > > -- > Thanks, > > Vivek > > > -----Original Message----- > From: Kochba, Alon [mailto:[email protected]] > Sent: Tuesday, March 21, 2017 8:02 PM > To: Jozef Bacigál <[email protected]>; Jamo Luhrsen > <[email protected]>; [email protected]; N > Vivekanandan <[email protected]> > Cc: [email protected] > Subject: RE: [openflowplugin-dev] Bug 8025 - missing method to use barrier > when installing rules and giving packet_out > > +netvirt-dev > > Vivek, you mentioned seeing problems with groupmod + flowmod order - do you > know if we are using FRS or FRM? > It seems openflowplugin does supposedly have support for this with barrier in > between when using FRS. > > Jozef what would be the API to maintain order between these writes, is there > some assumption on how they are installed? > > --alon > > > -----Original Message----- > From: Jozef Bacigál [mailto:[email protected]] > Sent: Tuesday, 21 March 2017 13:08 > To: Kochba, Alon <[email protected]>; Jamo Luhrsen <[email protected]>; > [email protected] > Subject: RE: [openflowplugin-dev] Bug 8025 - missing method to use barrier > when installing rules and giving packet_out > > Hi Alon, > > Yes you right config is unpredictable. Still you can use > SalFlowService/SalGroupService instead of config and you got the requested > functionality. > But if you use config to put flow mods even barrier, it can later on device > than packet out. > The second case (group mod + flow mod) it is well working with FRS instead of > FRM, because FRS sending barrier when needed. > > Jozef > > -----Original Message----- > From: Kochba, Alon [mailto:[email protected]] > Sent: Tuesday, March 21, 2017 10:56 AM > To: Jozef Bacigál <[email protected]>; Jamo Luhrsen > <[email protected]>; [email protected] > Subject: RE: [openflowplugin-dev] Bug 8025 - missing method to use barrier > when installing rules and giving packet_out > > Hi Jozef, > > Thanks for the reply. > We understand we can use statistics for this today - but we want to avoid > that as relying on statistics does not scale very well. > > We would like openflowplugin to expose an API that takes advantage of the > barrier feature as defined in the openflow spec (flow_mod + barrier + packet > out, or group_mod + barrier + flow_mod). > > --alon > > > -----Original Message----- > From: Jozef Bacigál [mailto:[email protected]] > Sent: Tuesday, 21 March 2017 10:47 > To: Jamo Luhrsen <[email protected]>; > [email protected]; Kochba, Alon <[email protected]> > Subject: RE: [openflowplugin-dev] Bug 8025 - missing method to use barrier > when installing rules and giving packet_out > > Hi Jamo, > > If I got it, you need to install two flows, and then send a packet in this > order. So only solution right now, quite easy is, to push the flows into > configuration and wait for statistics to be sure flow are installed and then > and only then send the packet. You don't need to run statistics periodically, > there is an direct RPC statistics gathering, you can run it to ensure the > flows are installed. > > Jozef > > -----Original Message----- > From: Jamo Luhrsen [mailto:[email protected]] > Sent: Monday, March 20, 2017 11:42 PM > To: [email protected]; Kochba, Alon <[email protected]> > Subject: [openflowplugin-dev] Bug 8025 - missing method to use barrier when > installing rules and giving packet_out > > Hi OFP, > > I just raised a bug/enhancement-request: > > https://bugs.opendaylight.org/show_bug.cgi?id=8025 > > Alon had sent an initial inquiry (see bug) about this, but we didn't hear > back. > Hoping that it can get some visibility with OFP at some point. > > The general problem for netvirt which consumes the plugin is that we are > running in to race conditions which are ugly (hard to reproduce, hard to > debug) and will be painful for end users when they hit them. The thinking is > that with this ability exposed, we can eliminate the races in a fundamental > way provided by the openflow protocol. > > Thanks, > JamO > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
