<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:53:28 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>[YANGTOOLS-512] Deleted Flow in config &quot;magically&quot; shows up after node restart.</title>
                <link>https://jira.opendaylight.org/browse/YANGTOOLS-512</link>
                <project id="10188" key="YANGTOOLS">yangtools</project>
                    <description>&lt;p&gt;A flow that is deleted in config ds, appears after node restart.&lt;/p&gt;

&lt;p&gt;Steps to reproduce:&lt;/p&gt;

&lt;p&gt;1) start controller with bin/karaf&lt;/p&gt;

&lt;p&gt;2) install odl-openflowplugin-flow-services-ui or odl-openflowplugin-flow-services-ui-li&lt;/p&gt;

&lt;p&gt;3) enter the &quot;magic&quot; sequence:&lt;/p&gt;

&lt;p&gt;3.1) add a flow, like example below or anything you like:&lt;/p&gt;

&lt;p&gt;&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&amp;gt;&lt;br/&gt;
&amp;lt;flow xmlns=&quot;urn:opendaylight:flow:inventory&quot;&amp;gt;&lt;br/&gt;
    &amp;lt;hard-timeout&amp;gt;0&amp;lt;/hard-timeout&amp;gt;&lt;br/&gt;
    &amp;lt;idle-timeout&amp;gt;0&amp;lt;/idle-timeout&amp;gt;&lt;br/&gt;
    &amp;lt;priority&amp;gt;2&amp;lt;/priority&amp;gt;&lt;br/&gt;
    &amp;lt;flow-name&amp;gt;flow1&amp;lt;/flow-name&amp;gt;&lt;br/&gt;
    &amp;lt;match&amp;gt;&lt;br/&gt;
        &amp;lt;ethernet-match&amp;gt;&lt;br/&gt;
            &amp;lt;ethernet-type&amp;gt;&lt;br/&gt;
                &amp;lt;type&amp;gt;2048&amp;lt;/type&amp;gt;&lt;br/&gt;
            &amp;lt;/ethernet-type&amp;gt;&lt;br/&gt;
        &amp;lt;/ethernet-match&amp;gt;&lt;br/&gt;
        &amp;lt;ipv4-destination&amp;gt;10.0.10.0/24&amp;lt;/ipv4-destination&amp;gt;&lt;br/&gt;
    &amp;lt;/match&amp;gt;&lt;br/&gt;
    &amp;lt;id&amp;gt;1&amp;lt;/id&amp;gt;&lt;br/&gt;
    &amp;lt;table_id&amp;gt;0&amp;lt;/table_id&amp;gt;&lt;br/&gt;
    &amp;lt;instructions&amp;gt;&lt;br/&gt;
        &amp;lt;instruction&amp;gt;&lt;br/&gt;
            &amp;lt;order&amp;gt;0&amp;lt;/order&amp;gt;&lt;br/&gt;
            &amp;lt;apply-actions&amp;gt;&lt;br/&gt;
                &amp;lt;action&amp;gt;&lt;br/&gt;
                    &amp;lt;output-action&amp;gt;&lt;br/&gt;
                        &amp;lt;output-node-connector&amp;gt;1&amp;lt;/output-node-connector&amp;gt;&lt;br/&gt;
                    &amp;lt;/output-action&amp;gt;&lt;br/&gt;
                    &amp;lt;order&amp;gt;0&amp;lt;/order&amp;gt;&lt;br/&gt;
                &amp;lt;/action&amp;gt;&lt;br/&gt;
            &amp;lt;/apply-actions&amp;gt;&lt;br/&gt;
        &amp;lt;/instruction&amp;gt;&lt;br/&gt;
    &amp;lt;/instructions&amp;gt;&lt;br/&gt;
&amp;lt;/flow&amp;gt;&lt;/p&gt;

&lt;p&gt;3.2) Remove the flow&lt;/p&gt;

&lt;p&gt;3.3) Add again the same flow&lt;/p&gt;

&lt;p&gt;3.4) Remove again the flow&lt;/p&gt;

&lt;p&gt;4) Stop controller (i.e. logout)&lt;/p&gt;

&lt;p&gt;5) Start controller bin/karaf&lt;/p&gt;

&lt;p&gt;Deleted flow is there in config!&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="22932">YANGTOOLS-512</key>
            <summary>Deleted Flow in config &quot;magically&quot; shows up after node restart.</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <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="10000">Done</resolution>
                                        <assignee username="rovarga">Robert Varga</assignee>
                                    <reporter username="ecelgp">Luis Gomez</reporter>
                        <labels>
                    </labels>
                <created>Fri, 25 Sep 2015 22:11:34 +0000</created>
                <updated>Sun, 10 Apr 2022 18:35:38 +0000</updated>
                            <resolved>Tue, 13 Oct 2015 12:57:33 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>8</watches>
                                                                                                                <comments>
                            <comment id="43536" author="moraja@cisco.com" created="Fri, 25 Sep 2015 22:26:00 +0000"  >&lt;p&gt;After deleting the flow and before restarting the controller are you able to see the flow in the datastore?&lt;/p&gt;</comment>
                            <comment id="43537" author="ecelgp" created="Fri, 25 Sep 2015 22:27:57 +0000"  >&lt;p&gt;No, the flow adds/removes with no issues before the restart.&lt;/p&gt;</comment>
                            <comment id="43538" author="moraja@cisco.com" created="Fri, 25 Sep 2015 22:33:05 +0000"  >&lt;p&gt;On which version did you encounter this problem? Is it reproducible on stable/lithium?&lt;/p&gt;</comment>
                            <comment id="43539" author="ecelgp" created="Fri, 25 Sep 2015 22:35:25 +0000"  >&lt;p&gt;both stable/lithium and master.&lt;/p&gt;</comment>
                            <comment id="43540" author="ecelgp" created="Fri, 25 Sep 2015 22:46:05 +0000"  >&lt;p&gt;I have just reproduced with latest stable/lithium distro from Nexus.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.3.2-SNAPSHOT/distribution-karaf-0.3.2-20150925.203437-84.zip&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/0.3.2-SNAPSHOT/distribution-karaf-0.3.2-20150925.203437-84.zip&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;BR/Luis&lt;/p&gt;</comment>
                            <comment id="43541" author="moraja@cisco.com" created="Sat, 26 Sep 2015 02:23:31 +0000"  >&lt;p&gt;See &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1297&quot; title=&quot;Clustering: Journal recovery error on restart&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1297&quot;&gt;&lt;del&gt;CONTROLLER-1297&lt;/del&gt;&lt;/a&gt; - It was fixed in helium by changing the journal-recovery batch size to 1. &lt;/p&gt;

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

&lt;p&gt;The workaround on stable/lithium for this particular bug right now is to set shard-journal-recovery-log-batch-size to 1 in etc/org.opendaylight.controller.cluster.datastore.cfg. The bug however appears to be in the underlying DataTree code I presume because when we do the operations described in this bug in separate transactions it produces a different output than when we do the same set of operations in a single transaction on recovery.&lt;/p&gt;</comment>
                            <comment id="43542" author="vishnoianil@gmail.com" created="Sat, 26 Sep 2015 13:18:17 +0000"  >&lt;p&gt;we do similar bug in ovsdb plugin as well, when bridge related config data pops up again in the data store, after restart. I will try this workaround and see if it works.&lt;/p&gt;</comment>
                            <comment id="43543" author="ecelgp" created="Sun, 27 Sep 2015 17:17:37 +0000"  >&lt;p&gt;Workaround suggested by Moiz works, at least for the issue reported.&lt;/p&gt;</comment>
                            <comment id="43544" author="rovarga" created="Wed, 30 Sep 2015 12:40:06 +0000"  >&lt;p&gt;Not an MD-SAL issue, but rather CDS.&lt;/p&gt;</comment>
                            <comment id="43545" author="moraja@cisco.com" created="Wed, 30 Sep 2015 14:52:25 +0000"  >&lt;p&gt;Robert were you able to test out DataTree in this scenario (add, delete, add, delete of the same node) to confirm that this is not a DataTree issue? &lt;/p&gt;

&lt;p&gt;Note that the issue is when we take four operations that were done in separate transactions and put it on a single transaction then this problem happens - and not when they are replayed on a single transaction.&lt;/p&gt;</comment>
                            <comment id="43546" author="rovarga" created="Wed, 30 Sep 2015 15:24:07 +0000"  >&lt;p&gt;Well, no, as there is no description of what the operations on DataTree are. Given that CDS data tree recovery is not a single write, but rather a series of operations from the journal, it is not clear what the before-state, DataTreeModification and after-state looks like.&lt;/p&gt;</comment>
                            <comment id="43547" author="moraja@cisco.com" created="Wed, 30 Sep 2015 15:35:50 +0000"  >&lt;p&gt;The test case is simple,&lt;/p&gt;

&lt;p&gt;Tx1 -&amp;gt; Add Flow 1 -&amp;gt; DTC 1&lt;br/&gt;
Tx2 -&amp;gt; Remove Flow 1 -&amp;gt; DTC 2 &lt;br/&gt;
Tx3 -&amp;gt; Add Flow 1 -&amp;gt; DTC 3&lt;br/&gt;
Tx3 -&amp;gt; Remove Flow 1 -&amp;gt; DTC 4&lt;/p&gt;

&lt;p&gt;Each transaction yields a DataTreeCandidate which we store in the journal.&lt;/p&gt;

&lt;p&gt;On recovery,&lt;/p&gt;

&lt;p&gt;Tx1 -&amp;gt; Apply (DTC1, DTC2, DTC3, DTC4) -&amp;gt; This triggers the bug&lt;/p&gt;

&lt;p&gt;If instead we do the following,&lt;/p&gt;

&lt;p&gt;Tx1 -&amp;gt; Apply DTC1&lt;br/&gt;
Tx2 -&amp;gt; Apply DTC2&lt;br/&gt;
Tx3 -&amp;gt; Apply DTC3&lt;br/&gt;
Tx4 -&amp;gt; Apply DTC4&lt;/p&gt;

&lt;p&gt;This works just fine. &lt;/p&gt;

&lt;p&gt;I am trying to reproduce the bug in a test case - so stay tuned.&lt;/p&gt;</comment>
                            <comment id="43548" author="moraja@cisco.com" created="Wed, 30 Sep 2015 16:59:56 +0000"  >&lt;p&gt;I&apos;ve reproduced this problem using a unit test &lt;/p&gt;

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

&lt;p&gt;I believe this shows the issue with the DataTree.&lt;/p&gt;</comment>
                            <comment id="43549" author="rovarga" created="Mon, 5 Oct 2015 14:43:59 +0000"  >&lt;p&gt;As the data tree candididates are applied, the modification to be applied looks like this:&lt;/p&gt;

&lt;p&gt;MutableDataTree [modification=NodeModification [identifier=(urn:ietf:params:xml:ns:netconf:base:1.0)data, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars=NodeModification &lt;span class=&quot;error&quot;&gt;&amp;#91;identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars, modificationType=WRITE, childModification={}&amp;#93;&lt;/span&gt;}]]&lt;/p&gt;

&lt;p&gt;MutableDataTree [modification=NodeModification [identifier=(urn:ietf:params:xml:ns:netconf:base:1.0)data, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars, modificationType=WRITE, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)name=altima}
&lt;p&gt;]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)name=altima}
&lt;p&gt;], modificationType=DELETE, childModification={}]}]}]}]]&lt;/p&gt;

&lt;p&gt;MutableDataTree [modification=NodeModification [identifier=(urn:ietf:params:xml:ns:netconf:base:1.0)data, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars, modificationType=WRITE, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)name=altima}
&lt;p&gt;]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)name=altima}
&lt;p&gt;], modificationType=WRITE, childModification={}]}]}]}]]&lt;/p&gt;

&lt;p&gt;MutableDataTree [modification=NodeModification [identifier=(urn:ietf:params:xml:ns:netconf:base:1.0)data, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)cars, modificationType=WRITE, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)name=altima}
&lt;p&gt;]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)car[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test:cars?revision=2014-03-13)name=altima}
&lt;p&gt;], modificationType=NONE, childModification={}]}]}]}]]&lt;/p&gt;


&lt;p&gt;The important thing to note is that the top-level write after the first transaction already contains the &apos;altima&apos; node in its data. Note that for second operation we carry a DELETE operation, for third we have an explicit WRITE.&lt;/p&gt;

&lt;p&gt;So when the second DELETE operation comes along, it sees a WRITE operation on non-preexisting data and turns it into a NONE operation. When we then apply this modification, WRITE is processed as usual and the other operations turn out to be no-ops &amp;#8211; hence altima looks like it&apos;s been resurrected.&lt;/p&gt;

&lt;p&gt;The problem is that the original node is resolved from the underlying snapshot, not the WRITE operation into which the modification is nested. In theory we should be able to set the before-state to the data from that write operation, which should have the effect of the fourth operation seeing this as a DELETE on data we wrote, but which has pre-existing data &amp;#8211; thus resolving to a DELETE node (not NONE), hence achieving the same state we see after two operations.&lt;/p&gt;</comment>
                            <comment id="43550" author="rovarga" created="Mon, 5 Oct 2015 17:35:01 +0000"  >&lt;p&gt;Be: &lt;a href=&quot;https://git.opendaylight.org/gerrit/27924&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/27924&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="43551" author="tony.tkacik@gmail.com" created="Tue, 13 Oct 2015 12:57:33 +0000"  >&lt;p&gt;Merged in Beryllium and stable/lithium (Lithium SR-3)&lt;/p&gt;</comment>
                    </comments>
                    <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>4359</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=4359]]></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="10326"><![CDATA[Lithium-3]]></customfieldvalue>

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

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