<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:35:37 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>[OVSDB-146] race condition between northbound and southbound events</title>
                <link>https://jira.opendaylight.org/browse/OVSDB-146</link>
                <project id="10158" key="OVSDB">ovsdb</project>
                    <description>&lt;p&gt;When an interface is deleted, processRowUpdate (SouthboundHandler.java) tries to get the tenant network corresponding to this interface. But, in that implementation, the network will be null if the corresponding neutron port has been deleted before.&lt;/p&gt;

&lt;p&gt;It seems working when the owner is compute:nova or network:dhcp (reference setup). My logs show processRowUpdate is always called before doNeutronPortDeleted (PortHandler.java).&lt;/p&gt;

&lt;p&gt;It doesn&apos;t work in case of router_interface ports owned by l3-agent (my logs show that doNeutronPortDeleted is always called before). Network is null in processRowUpdate and then handleInterfaceDelete doesn&apos;t manage the flows to delete.&lt;/p&gt;

&lt;p&gt;Referring to ml2 plugin.py, we can&apos;t assume that l3-agent removes the interface before the call from delete_port_postcommit (mechanism_odl.py). More generally, we can&apos;t think that the interface will be deleted before the http delete request.&lt;/p&gt;

&lt;p&gt;A solution would be to manage network data in southbound delete events (eg. virtual tenant identifier) to handle interface delete. More disruptive solutions are possible too.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: Linux&lt;br/&gt;
Platform: PC&lt;/p&gt;</environment>
        <key id="21838">OVSDB-146</key>
            <summary>race condition between northbound and southbound events</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="-1">Unassigned</assignee>
                                    <reporter username="ollivier.cedric@gmail.com">C&#233;dric Ollivier</reporter>
                        <labels>
                    </labels>
                <created>Thu, 23 Apr 2015 09:36:01 +0000</created>
                <updated>Thu, 19 Oct 2017 21:28:25 +0000</updated>
                            <resolved>Mon, 25 Jan 2016 15:15:26 +0000</resolved>
                                    <version>unspecified</version>
                                                    <component>openstack.net-virt</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>5</watches>
                                                                                                                <comments>
                            <comment id="40788" author="flavio@flaviof.com" created="Thu, 23 Apr 2015 20:57:00 +0000"  >&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;16:47:48&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	I think this is really serious and forbid at least the use of l3-agent&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:47:57&amp;#93;&lt;/span&gt;  &amp;lt;flaviof&amp;gt;	ack&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:48:53&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	As it&apos;s a race condition it could happen by any port removal&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:49:29&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	the exchanges between nova and neutron save us &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:49:50&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	I don&apos;t analyse deeply the dhcp case..&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:49:51&amp;#93;&lt;/span&gt;  &amp;lt;flaviof&amp;gt;	l3-agent is not part of odl... not sure I understand how that is affected&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:50:35&amp;#93;&lt;/span&gt;  &amp;lt;flaviof&amp;gt;	mind you, the ovs port add/remove is not done by ovsdb in odl, it is done by nova.&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:50:42&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	It&apos;s a race condition raised by ports managed by l3-agent... But It could happen with dhcp port or VMS&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:51:20&amp;#93;&lt;/span&gt;  &amp;lt;flaviof&amp;gt;	ack&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:51:37&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	agree. But if neutron sends to ODL port deleted before nova calls ovs-vsctl del-port&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:52:46&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	itwill fail&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:53:42&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	In case of l3 agent, ML2 (ODL driver) sends the HTTP delete request before ovs-vsctl del-port&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:53:50&amp;#93;&lt;/span&gt;  &amp;lt;flaviof&amp;gt;	make sense.&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:54:03&amp;#93;&lt;/span&gt;  &amp;lt;flaviof&amp;gt;	it definitely should be order agnostic.&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;16:56:31&amp;#93;&lt;/span&gt;  &amp;lt;ollivier&amp;gt;	even if ODL can manage L3 forwarding and avoid l3-agent now, any port can raise this race condition...&lt;/p&gt;</comment>
                            <comment id="40789" author="ollivier.cedric@gmail.com" created="Sun, 3 May 2015 12:05:44 +0000"  >&lt;p&gt;It doesn&apos;t work in case of network:dhcp ports when the subnet is deleted. You must modify the subnet before deleting it (enable_dhcp=False).&lt;/p&gt;</comment>
                            <comment id="40790" author="pbandzi@cisco.com" created="Wed, 3 Jun 2015 16:04:35 +0000"  >&lt;p&gt;Tested in OPNFV project.&lt;br/&gt;
&lt;a href=&quot;https://build.opnfv.org/ci/view/functest/job/functest-opnfv-jump-2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://build.opnfv.org/ci/view/functest/job/functest-opnfv-jump-2&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;used test from ODL integration suite:&lt;br/&gt;
&lt;a href=&quot;https://github.com/opendaylight/integration/tree/master/test/csit/suites/openstack/neutron&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/opendaylight/integration/tree/master/test/csit/suites/openstack/neutron&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Plus added similar test for delete created network according ID&lt;/p&gt;

&lt;p&gt;Network, Subnet, Port still remains in ODL even when they were deleted from neutron.&lt;/p&gt;

&lt;p&gt;to reproduce:&lt;br/&gt;
git clone &lt;a href=&quot;https://gerrit.opnfv.org/gerrit/functest&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://gerrit.opnfv.org/gerrit/functest&lt;/a&gt;&lt;br/&gt;
cd functest/testcases/Controllers/ODL/CI&lt;br/&gt;
./create_env.sh&lt;br/&gt;
ODL_IP=&amp;lt;odl_ip&amp;gt; ODL_PORT=&amp;lt;odl_port&amp;gt; PASS=&amp;lt;ostack_admin_pass&amp;gt; NEUTRON_IP=&amp;lt;neutorn_ip&amp;gt; ./start_tests.sh&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>3052</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=3052]]></customfieldvalue>

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

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