<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:33:36 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[OPNFLWPLUG-870] missing method to use barrier when installing dependant groups+flows or flows+packet_out</title>
                <link>https://jira.opendaylight.org/browse/OPNFLWPLUG-870</link>
                <project id="10155" key="OPNFLWPLUG">OpenFlowPlugin</project>
                    <description>&lt;p&gt;origin email request below, but entire thread can be found here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://lists.opendaylight.org/pipermail/openflowplugin-dev/2017-March/006764.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://lists.opendaylight.org/pipermail/openflowplugin-dev/2017-March/006764.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;-----------------------------------------------------------------------------&lt;/p&gt;

&lt;p&gt;Hi,&lt;/p&gt;



&lt;p&gt;We have a CSIT test in netvirt that tests UDP connectivity using netvirt&apos;s SNAT feature, that&apos;s sporadically failing.&lt;/p&gt;

&lt;p&gt;The same test in TCP succeeds all the time.&lt;/p&gt;



&lt;p&gt;We debugged the flows and it seems there is a race between these three events - ODL receives the initial packet, and then:&lt;/p&gt;

&lt;p&gt;a.      Installs an inbound flow using NaptEventHandler#buildAndInstallNatFlows()&lt;/p&gt;

&lt;p&gt;b.      Installs an outbound flow using NaptEventHandler#buildAndInstallNatFlows()&lt;/p&gt;

&lt;p&gt;c.      Sends the original packet as a packet out to OFPP_TABLE for re-processing by pipeline.&lt;/p&gt;



&lt;p&gt;For the test to work properly, (c) must happen after (a) and (b) have been programmed to the switch properly.&lt;/p&gt;

&lt;p&gt;The flows are written using genius&apos; mdsalManager.syncInstallFlow(), which does a synchronous write into the flows CONFIG data store.&lt;/p&gt;

&lt;p&gt;The packet out is sent via openflowplugin PacketProcessingService.transmitPacket()&lt;/p&gt;



&lt;p&gt;Is there a way to ensure (c) is triggered only after (a) and (b) are properly configured?&lt;/p&gt;

&lt;p&gt;Perhaps delay the packet out somehow? Use barrier somehow?&lt;/p&gt;



&lt;p&gt;If this is not a possibility, we can try two things that are pretty ugly:&lt;/p&gt;

&lt;p&gt;a.      Reverse (a) and (b) - because then if only (a) is installed (which seems more common), the request would have to be re-punted to the ODL, delaying it. &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; will do that, but we need to run it many times to verify it helps.&lt;/p&gt;

&lt;p&gt;This still won&apos;t fix anything if (c) happens before both (a) and (b).&lt;/p&gt;

&lt;p&gt;b.      Leave the entire bug, but try to fix this on a test level - add delay to the server&apos;s response or use something other than netcat that might retry UDP.&lt;/p&gt;



&lt;p&gt;The reason this might be ok, is that we have flow based SNAT coming up in Carbon which should eliminate this race.&lt;/p&gt;



&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/52380&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/52380&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;--alon&lt;/p&gt;


&lt;p&gt;-----------------------------------------------------------------------------&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="28138">OPNFLWPLUG-870</key>
            <summary>missing method to use barrier when installing dependant groups+flows or flows+packet_out</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="1" iconUrl="https://jira.opendaylight.org/images/icons/priorities/blocker.svg">Highest</priority>
                        <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10002">Duplicate</resolution>
                                        <assignee username="Hematg">Hema Gopalakrishnan</assignee>
                                    <reporter username="jluhrsen">Jamo Luhrsen</reporter>
                        <labels>
                    </labels>
                <created>Mon, 20 Mar 2017 22:37:30 +0000</created>
                <updated>Mon, 27 Sep 2021 09:02:01 +0000</updated>
                            <resolved>Mon, 16 Apr 2018 15:58:06 +0000</resolved>
                                                                    <component>General</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>9</watches>
                                                                                                                <comments>
                            <comment id="58824" author="ecelgp" created="Mon, 20 Mar 2017 23:07:32 +0000"  >&lt;p&gt;I hope we have a way to guarantee order when things are sent to the same switch, otherwise this seems like a required enhancement.&lt;/p&gt;</comment>
                            <comment id="58825" author="tomas.slusny@pantheon.tech" created="Tue, 21 Mar 2017 19:51:38 +0000"  >&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

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

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;2nd option example:&lt;br/&gt;
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.&lt;/p&gt;

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

&lt;p&gt;Tomas, thanks for the answer.&lt;br/&gt;
It seems you only referred to the flow_mod+packet_out dependency.&lt;/p&gt;

&lt;p&gt;How about group_mod+flow_mod for FRM?&lt;br/&gt;
These both go through DS, and can be synchronized, Anil mentioned this is a bug if it doesn&apos;t work.&lt;br/&gt;
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.&lt;/p&gt;</comment>
                            <comment id="58827" author="shague@redhat.com" created="Mon, 15 May 2017 20:38:36 +0000"  >&lt;p&gt;Anil, we added a hack in NetVirt to get around this issue that uses barriers to force syncing the order.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/54349/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/54349/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="58828" author="anipbu" created="Mon, 15 May 2017 22:42:55 +0000"  >&lt;p&gt;Patch &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/56786/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/56786/&lt;/a&gt; was successfully merged.  Can we mark this bug as fixed and resolved?&lt;/p&gt;</comment>
                            <comment id="58829" author="vishnoianil@gmail.com" created="Mon, 15 May 2017 22:50:19 +0000"  >&lt;p&gt;@Sam, cool, i believe that&apos;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. &lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;</comment>
                            <comment id="58830" author="abhijit2511" created="Mon, 16 Oct 2017 16:03:56 +0000"  >&lt;p&gt;Moved to Hema from Anil.&lt;/p&gt;</comment>
                            <comment id="60209" author="abhijit2511" created="Mon, 27 Nov 2017 17:01:30 +0000"  >&lt;p&gt;Any luck on this Hema?&lt;/p&gt;</comment>
                            <comment id="60387" author="vishnoianil@gmail.com" created="Tue, 12 Dec 2017 00:28:43 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Hematg&quot; class=&quot;user-hover&quot; rel=&quot;Hematg&quot;&gt;Hematg&lt;/a&gt; Please let me know if you are planning to work on this bug, else i will more it unassigned pool.&lt;/p&gt;</comment>
                            <comment id="60946" author="vishnoianil@gmail.com" created="Tue, 6 Feb 2018 05:26:56 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Hematg&quot; class=&quot;user-hover&quot; rel=&quot;Hematg&quot;&gt;Hematg&lt;/a&gt; any update on this ?&lt;/p&gt;</comment>
                            <comment id="61428" author="vishnoianil@gmail.com" created="Tue, 6 Mar 2018 05:52:46 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Arunprakash&quot; class=&quot;user-hover&quot; rel=&quot;Arunprakash&quot;&gt;Arunprakash&lt;/a&gt; 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.&lt;/p&gt;</comment>
                            <comment id="61429" author="vishnoianil@gmail.com" created="Tue, 6 Mar 2018 05:53:13 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Arunprakash&quot; class=&quot;user-hover&quot; rel=&quot;Arunprakash&quot;&gt;Arunprakash&lt;/a&gt; please link the Jira ticket for FRM changes to this ticket.&lt;/p&gt;</comment>
                            <comment id="62459" author="vishnoianil@gmail.com" created="Mon, 16 Apr 2018 15:57:55 +0000"  >&lt;p&gt;Above bug will be fixed through &lt;a href=&quot;https://jira.opendaylight.org/browse/OPNFLWPLUG-991&quot; title=&quot;FRM: Flow Group Dependency support&quot; class=&quot;issue-link&quot; data-issue-key=&quot;OPNFLWPLUG-991&quot;&gt;&lt;del&gt;OPNFLWPLUG-991&lt;/del&gt;&lt;/a&gt;. Please see 991 for update on this issue.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10002">
                    <name>Duplicate</name>
                                            <outwardlinks description="duplicates">
                                        <issuelink>
            <issuekey id="29485">OPNFLWPLUG-991</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>8025</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=8025]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i033tj:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>