<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:38:49 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>[SFC-167] RSP is not found</title>
                <link>https://jira.opendaylight.org/browse/SFC-167</link>
                <project id="10167" key="SFC">sfc</project>
                    <description>&lt;p&gt;We are having a blocking issue in a OPNFV SFC test case with the classifier (we are using old netvirt &#8220;odl-ovsdb-openstack&#8221; and the official SR0 of Boron). We don&#8217;t understand why but the first time we create a classification rule, no classification flows appear in the pipeline (table=11 only has the default flow pointing to table=21). However, if we delete that rule and create a new one, then it works.&lt;/p&gt;

&lt;p&gt;These are the logs we get in karaf.log the first time we try (not working):&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://pastebin.com/akTeSrz6&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://pastebin.com/akTeSrz6&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;These are the logs we get in karaf.log the second time we try (after deleting the previous classifier rule. This works!):&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://pastebin.com/P8LQwUiN&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://pastebin.com/P8LQwUiN&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;As you can observe, both fail to get a rsp when trying getRenderedServicePath but the second time we try, it seems as if it tries again to get the rsp and gets it. Note, that before the creation of the classifier was triggered, I queried ODL to check if the RSP was there and yes, it was there. Here are two screenshots with the stack at the moment when it tries to read the rsp from md-sal:&lt;/p&gt;

&lt;p&gt;Not working: &lt;a href=&quot;https://www.dropbox.com/s/38dy03nnxiclbv3/capture%20-%20not%20working.PNG?dl=0&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.dropbox.com/s/38dy03nnxiclbv3/capture%20-%20not%20working.PNG?dl=0&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Working: &lt;a href=&quot;https://www.dropbox.com/s/9y8uhv5u96xyrb8/Capture%20-%20working%20%281%29.PNG?dl=0&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.dropbox.com/s/9y8uhv5u96xyrb8/Capture%20-%20working%20%281%29.PNG?dl=0&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;That is line 71 of SfcUtils.java:&lt;/p&gt;

&lt;p&gt;return mdsalUtils.read(LogicalDatastoreType.OPERATIONAL, getRspId(rspName));&lt;/p&gt;

&lt;p&gt;The &#8220;capture &#8211; not working&#8221; shows the stack when it will return rsp = null. The &#8220;capture working&#8221; shows the stack when it returns a correct rsp and consequently, correct flows rules are written in the pipeline. Observe that when it works, the call was triggered from &#8220;removeClassifierRules&#8221; and when it does not work, the call is triggered by &#8220;addClassifierRules&#8221;. In other words, the log output rsp=null is a result of calling the method &#8220;addClassifierRules&#8221;, whereas the log output where rsp is not null is a result of calling the method &#8220;removeClassifierRules&#8221;. As you can see in the second logs, I don&#8217;t understand why but when we create the second classifier, both methods are called, first &#8220;addClassifierRules&#8221; and afterwards &#8220;removeClassifierRules&#8221;.&lt;/p&gt;

&lt;p&gt;I also noticed that when I remove a classifier rule, it does not get deleted from the pipeline unless I create a classifier rule. So it is as if the deletion task is pending until a creation task appears and then, the creation task checks if there are any deletion tasks to be done.&lt;/p&gt;

&lt;p&gt;So, my hypothesis is: the code only gets the right rsp when removing the classifier rules. This removal action is triggered when calling the creation of rules and then it removes the rules which must be removed and adds the appropriate rules. When we try the first time, as there is nothing to be deleted, it does not work because only the method &#8220;addClassifierRules&#8221; is called and that one, for unkown reasons to me, fails to get the rsp.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="24193">SFC-167</key>
            <summary>RSP is not found</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="10004" iconUrl="https://jira.opendaylight.org/images/icons/status_generic.gif" description="">Verified</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="mbuil@suse.com">Manuel Buil</reporter>
                        <labels>
                    </labels>
                <created>Wed, 26 Oct 2016 14:29:06 +0000</created>
                <updated>Thu, 19 Oct 2017 21:29:01 +0000</updated>
                            <resolved>Thu, 3 Nov 2016 15:56:53 +0000</resolved>
                                    <version>unspecified</version>
                                                    <component>General</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="46707" author="shague@redhat.com" created="Wed, 26 Oct 2016 20:29:52 +0000"  >&lt;p&gt;Recap of what is in the thread...&lt;/p&gt;

&lt;p&gt;There has to be an rsp in the mdsal at the time the acl is created before netvirtsfc can add flows. In the logs captured that rsp does not exist. Sometime later an rsp is there and then flows are programmed. The adding of the rsp is out of scope from netvirtsfc.&lt;/p&gt;

&lt;p&gt;please attach full logs with trace enabled in both the sfc and netvirt projects. From that we can see the full flow and why the rsp is not written to mdsal.&lt;/p&gt;</comment>
                            <comment id="46708" author="ebrjohn" created="Fri, 28 Oct 2016 15:34:22 +0000"  >&lt;p&gt;We did some more testing with more debug logs and found the problem.&lt;/p&gt;

&lt;p&gt;The rsp (rendered service path, the actual service chain) is being created correctly, but we see it gets deleted 1 second later, before the netvirt classifier is created, thus the log message by netvirt that the rsp doesn&apos;t exist.&lt;/p&gt;

&lt;p&gt;We investigated further to see why/who deletes the rsp. We figured out that tacker creates everything correctly for the first rsp and then starts creating a second rsp. When tacker is creating the second rsp, it modifies the sff (service function forwarder), which currently causes SFC to delete the rsp.&lt;/p&gt;

&lt;p&gt;If the sff is deleted or if certain fields are modified, the rsp should be deleted. But in this case, the sff mods are minimal and the rsp should not be deleted. So the fix to sfc is when an sff is modified, only delete the rsp when absolutely necessary.&lt;/p&gt;</comment>
                            <comment id="46709" author="ebrjohn" created="Fri, 28 Oct 2016 15:38:05 +0000"  >&lt;p&gt;This is fixed in stable/boron here:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/47739/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/47739/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Its currently being tested in OPNFV. Upon completion there, we&apos;ll merge the patch and close this bug.&lt;/p&gt;

&lt;p&gt;Brady&lt;/p&gt;</comment>
                            <comment id="46710" author="anipbu" created="Fri, 28 Oct 2016 16:37:33 +0000"  >&lt;p&gt;A patch was submitted to fix this bug in Boron SR1: &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/47739/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/47739/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;To better assess the impact of this bug and fix, could someone from your team please help us identify the following:&lt;br/&gt;
Regression: Is this bug a regression of functionality/performance/feature compared to Boron?&lt;br/&gt;
Severity: Could you elaborate on the severity of this bug?  Is this a BLOCKER such that we cannot release Boron-SR1 without it?  Is there a workaround such that we can write a release note?&lt;br/&gt;
Testing: Could you also elaborate on the testing of this patch?  How extensively has this patch been tested?  Is it covered by any unit tests or system tests?  &lt;br/&gt;
Impact: Does this fix impact any dependent projects?&lt;/p&gt;</comment>
                            <comment id="46711" author="ebrjohn" created="Fri, 28 Oct 2016 19:37:22 +0000"  >&lt;p&gt;Regression:&lt;br/&gt;
Is this bug a regression of functionality/performance/feature compared to Boron?&lt;/p&gt;

&lt;p&gt;No it is not, its been a failure for some time, and we just found it in OPNFV.&lt;/p&gt;


&lt;p&gt;Severity:&lt;br/&gt;
Could you elaborate on the severity of this bug?  Is this a BLOCKER such that we cannot release Boron-SR1 without it?  Is there a workaround such that we can write a release note?&lt;/p&gt;

&lt;p&gt;This is quite severe. With just a simple modification to a Service Function Forwarder (SFF) or Service Function (SF) all related Rendered Service Paths (RSPs, the actual service chains) are deleted. The RSP should only be deleted if either the SFF is deleted, the SF is deleted, or either is modified in such a way that the RSP is affected.&lt;/p&gt;


&lt;p&gt;Testing:&lt;br/&gt;
Could you also elaborate on the testing of this patch?  How extensively has this patch been tested?  Is it covered by any unit tests or system tests? &lt;/p&gt;

&lt;p&gt;Unit Tests were modified and added to ODL to test this patch. I also created a distro to test this patch in OPNFV, which is quite extensive.&lt;/p&gt;


&lt;p&gt;Impact:&lt;br/&gt;
Does this fix impact any dependent projects?&lt;/p&gt;

&lt;p&gt;No&lt;/p&gt;</comment>
                            <comment id="46712" author="ebrjohn" created="Fri, 28 Oct 2016 19:38:06 +0000"  >&lt;p&gt;This has been successfully tested in OPNFV. Closing.&lt;/p&gt;</comment>
                            <comment id="46713" author="anipbu" created="Tue, 1 Nov 2016 15:18:37 +0000"  >&lt;p&gt;Has this bug been verified as fixed in the latest Boron SR1 Build 20161030?&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10002">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="20031">NETVIRT-110</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </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>7039</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=7039]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Bug]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10204" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>ODL SR Target Milestone</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10307"><![CDATA[Boron-1]]></customfieldvalue>

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

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