<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:25:42 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>[NEUTRON-158] Dependency checking for Northbound API</title>
                <link>https://jira.opendaylight.org/browse/NEUTRON-158</link>
                <project id="10145" key="NEUTRON">neutron</project>
                    <description>&lt;p&gt;The Neutron Northbound API currently (almost) always just returns an &quot;OK&quot; (HTTP 200) reply. Any errors that occur when the requested resource creation/update did not succeed, including missing dependency (but also other internal problems), is &quot;lost&quot;&#160;and not communicated to&#160;the caller (and only appears in the log).&lt;/p&gt;

&lt;p&gt;The technical explanation for this is ODL general architecture based on decoupled asynchronous listening on a shared data model, and the lack of any &quot;feedback loop&quot; between Neutron and e.g. Netvirt (or, in theory, other listeners to the Neutron model).&lt;/p&gt;

&lt;p&gt;The goal of this issue is to provide feedback to callers for a first set of missing dependencies. It will not include work to address the more general problem of error handling and feedback for other internal problems than some dependencies.&lt;/p&gt;

&lt;p&gt;Events that are originally ordered in the OpenStack Journal can get out of order because (a) the clustered driver reading from the DB could read out of order; (b) the driver sending to clustered load balanced ODL could cause events to be stored out of order in the ODL data store. This will throw off applications such as netvirt which do not expect this.&lt;/p&gt;

&lt;p&gt;In order to compensate for this, we will make the ODL Neutron project return an HTTP error other than 2xx range code if its dependencies are not, yet, available in the data store. For example, in the case of &lt;a href=&quot;https://jira.opendaylight.org/browse/NEUTRON-149&quot; title=&quot;Security group and security rule events are not synced&quot; class=&quot;issue-link&quot; data-issue-key=&quot;NEUTRON-149&quot;&gt;NEUTRON-149&lt;/a&gt; a security rule which is written before a security group should be rejected. The validation happens, only, at the level of the Neutron model object data objects, not the internal netvirt or other models which eventually have created by the listeners in netvirt or other. The fact that e.g. a security rule requires a group with a certain ID (and all others like it), will be hard-coded in neutron.&lt;/p&gt;

&lt;p&gt;The initial implementation will focus on doing above for Create events. If at all and how to apply this to Update and Delete will be considered later under future issues with refined requirements.&lt;/p&gt;

&lt;p&gt;This work in ODL requires no changes to t the existing networking ODL driver code. Therefore we are not anticipating to make this a configurable optional feature via a switch, but just have this new behaviour active as the related changes will be merged.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://bugzilla.redhat.com/show_bug.cgi?id=1550699&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://bugzilla.redhat.com/show_bug.cgi?id=1550699&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
        <key id="29588">NEUTRON-158</key>
            <summary>Dependency checking for Northbound API</summary>
                <type id="10100" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="3" iconUrl="https://jira.opendaylight.org/images/icons/priorities/major.svg">Medium</priority>
                        <status id="3" iconUrl="https://jira.opendaylight.org/images/icons/statuses/inprogress.png" description="This issue is being actively worked on at the moment by the assignee.">In Progress</status>
                    <statusCategory id="4" key="indeterminate" colorName="yellow"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="jhershbe">Josh Hershberg</assignee>
                                    <reporter username="vorburger">Michael Vorburger</reporter>
                        <labels>
                            <label>csit:3node</label>
                    </labels>
                <created>Wed, 4 Apr 2018 14:19:44 +0000</created>
                <updated>Fri, 24 Aug 2018 11:22:25 +0000</updated>
                                                            <fixVersion>Neon</fixVersion>
                                    <component>northbound-api</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                                                            <comments>
                            <comment id="63157" author="vorburger" created="Mon, 28 May 2018 16:29:35 +0000"  >&lt;p&gt;We should pick a specific HTTP 4xx status code to return in case expected dependant objects are not (yet) present.&lt;/p&gt;

&lt;p&gt;Looking e.g. at the &lt;a href=&quot;https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Wikipedia page about HTTP status codes&lt;/a&gt;, the following all seem vaguely appropriate:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;409 Conflict: &lt;em&gt;Indicates that the request could not be processed because of conflict in the request, such as an edit conflict between multiple simultaneous update.&lt;/em&gt;&lt;/li&gt;
	&lt;li&gt;412 Precondition Failed (RFC 7232) : &lt;em&gt;The server does not meet one of the preconditions that the requester put on the request.&lt;/em&gt; Sounds neat, but strictly speaking we would not reply this because of a RFC 7232 compliant precondition header that the requester put on the request, of course.&lt;/li&gt;
	&lt;li&gt;417 Expectation Failed: &lt;em&gt;The server cannot meet the requirements of the Expect request-header field.&lt;/em&gt; Again, strictly speaking wrong, as of course we do actually use the Expect request-header field.&lt;/li&gt;
	&lt;li&gt;424 Failed Dependency (WebDAV; RFC 4918): &lt;em&gt;The request failed because it depended on another request and that request failed (e.g., a PROPPATCH).&lt;/em&gt; Neat fit, but again - we of course don&apos;t do RFC 4918 / WebDAV.&lt;/li&gt;
	&lt;li&gt;442: Totally arbitrary new one, &lt;a href=&quot;https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#The_number_42&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;I just made up&lt;/a&gt;! May be best and clearer than using an existing one?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;I will start with 442, and will let anyone who thinks that there is a more appropriate one please comment here.&lt;/p&gt;</comment>
                            <comment id="63159" author="jhershbe" created="Tue, 29 May 2018 06:19:17 +0000"  >&lt;p&gt;Alternatively, we could just use 400 and give a textual explanation.&lt;/p&gt;

&lt;p&gt;Or we could try &quot;402 Payment Required&quot; and see if we could make a little money &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="63168" author="vorburger" created="Tue, 29 May 2018 15:03:11 +0000"  >&lt;p&gt;Removing &lt;a href=&quot;https://jira.opendaylight.org/browse/GENIUS-122&quot; title=&quot;DataTreeEventCallbackRegistrar really needs a timeout&quot; class=&quot;issue-link&quot; data-issue-key=&quot;GENIUS-122&quot;&gt;&lt;del&gt;GENIUS-122&lt;/del&gt;&lt;/a&gt; as an &quot;is blocked by link&quot; - the current design won&apos;t need the DataTreeEventCallbackRegistrar.&lt;/p&gt;</comment>
                            <comment id="63551" author="vorburger" created="Wed, 20 Jun 2018 12:36:48 +0000"  >&lt;p&gt;&amp;gt; initial implementation will focus on doing above for Create events&lt;/p&gt;

&lt;p&gt;with the just merged&#160;&lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/72372&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;c/72372&lt;/a&gt;, this is now on master.&#160;&lt;/p&gt;

&lt;p&gt;First round covers it for SG / SR; others should replicate this to other Neutron entities.&lt;/p&gt;

&lt;p&gt;&amp;gt; If at all and how to apply this to Update&lt;/p&gt;

&lt;p&gt;this is now proposed &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/73248&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;c/73248&lt;/a&gt;,&#160;but may need some disucssion... will the delta sent in a PUT to modify alway contain all fields? For example, does a PUT to modify an existing SR have to have that &lt;tt&gt;security_group_id&lt;/tt&gt; field, like a POST to create must, or is that optional?&#160;Interested in your thoughts &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jhershbe&quot; class=&quot;user-hover&quot; rel=&quot;jhershbe&quot;&gt;jhershbe&lt;/a&gt;, &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=MikeKolesnik&quot; class=&quot;user-hover&quot; rel=&quot;MikeKolesnik&quot;&gt;MikeKolesnik&lt;/a&gt;, &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=thapar&quot; class=&quot;user-hover&quot; rel=&quot;thapar&quot;&gt;thapar&lt;/a&gt;...&lt;/p&gt;

&lt;p&gt;&amp;gt; and Delete will be considered later under future issues with refined requirements.&lt;/p&gt;

&lt;p&gt;Delete probably does not need Dependency Checking - forget that.&lt;/p&gt;</comment>
                            <comment id="63552" author="vorburger" created="Wed, 20 Jun 2018 12:44:57 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=shague&quot; class=&quot;user-hover&quot; rel=&quot;shague&quot;&gt;shague&lt;/a&gt; and I have agree to include this work under the umbrella of &quot;work required for better clustering&quot; (see label and Epic Link he just added), based on a private email exchange where &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=thapar&quot; class=&quot;user-hover&quot; rel=&quot;thapar&quot;&gt;thapar&lt;/a&gt;&#160;stated the following which &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=jhershbe&quot; class=&quot;user-hover&quot; rel=&quot;jhershbe&quot;&gt;jhershbe&lt;/a&gt; confirmed with &quot;it makes sense to me to add it here as well.&quot; &amp;amp; &quot;Yes, that is my thinking as well.&quot; in reply to:&lt;/p&gt;

&lt;blockquote&gt;&lt;p&gt;I thought it was more due to Openstack side HA issues. ODL Clustering wise, it will help as netvirt will be much less likely to get notifications out of order. A DS Read on dependency check kinda of ensures that services have already got notifications for earlier resource and will be ready to handle this one. It will help reduce lots of race and out of order issues and probably should help reduce some cross shard read and writes.&lt;/p&gt;&lt;/blockquote&gt;</comment>
                            <comment id="63671" author="vorburger" created="Mon, 25 Jun 2018 16:26:51 +0000"  >&lt;p&gt;&amp;gt; First round covers it for SG / SR; others should replicate this to other Neutron entities.&lt;/p&gt;

&lt;p&gt;the best way to organize this is probably with new sub-tasks for specific Neutron entities (TBC).&lt;/p&gt;</comment>
                            <comment id="64206" author="vorburger" created="Wed, 25 Jul 2018 11:21:13 +0000"  >&lt;p&gt;&amp;gt; the best way to organize this is probably with new sub-tasks for specific Neutron entities (TBC)&lt;/p&gt;

&lt;p&gt;I would love someone else to take this over at this point. What&apos;s missing is basically just implementing more &lt;tt&gt;areAllDependenciesAvailable()&lt;/tt&gt; methods, by replicating &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/72372/10/transcriber/src/main/java/org/opendaylight/neutron/transcriber/NeutronSecurityRuleInterface.java&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/72372/10/transcriber/src/main/java/org/opendaylight/neutron/transcriber/NeutronSecurityRuleInterface.java&lt;/a&gt; to all other Neutron entities.&lt;/p&gt;

&lt;p&gt;It&apos;s not particularly hard to do anymore (now that I&apos;ve completing creating all the infrastructure that was required for this underneath), but I&apos;m actually clueless about the Neutron entities...&#160;&lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/tongue.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="64480" author="vorburger" created="Thu, 2 Aug 2018 12:26:55 +0000"  >&lt;p&gt;&amp;gt; take this over at this point&lt;/p&gt;

&lt;p&gt;see &lt;a href=&quot;https://github.com/openstack/networking-odl/blob/master/networking_odl/journal/dependency_validations.py&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/openstack/networking-odl/blob/master/networking_odl/journal/dependency_validations.py&lt;/a&gt;&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10000">
                    <name>Blocks</name>
                                            <outwardlinks description="blocks">
                                        <issuelink>
            <issuekey id="26711">NEUTRON-149</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                            <subtask id="30511">NEUTRON-165</subtask>
                            <subtask id="30512">NEUTRON-166</subtask>
                            <subtask id="30513">NEUTRON-167</subtask>
                            <subtask id="30514">NEUTRON-168</subtask>
                            <subtask id="30515">NEUTRON-169</subtask>
                            <subtask id="30516">NEUTRON-170</subtask>
                            <subtask id="30517">NEUTRON-171</subtask>
                            <subtask id="30518">NEUTRON-172</subtask>
                            <subtask id="30519">NEUTRON-173</subtask>
                            <subtask id="30520">NEUTRON-174</subtask>
                            <subtask id="30521">NEUTRON-175</subtask>
                            <subtask id="30522">NEUTRON-176</subtask>
                            <subtask id="30523">NEUTRON-177</subtask>
                            <subtask id="30524">NEUTRON-178</subtask>
                            <subtask id="30525">NEUTRON-179</subtask>
                            <subtask id="30526">NEUTRON-180</subtask>
                            <subtask id="30527">NEUTRON-181</subtask>
                            <subtask id="30528">NEUTRON-182</subtask>
                            <subtask id="30529">NEUTRON-183</subtask>
                            <subtask id="30530">NEUTRON-184</subtask>
                            <subtask id="30531">NEUTRON-185</subtask>
                            <subtask id="30532">NEUTRON-186</subtask>
                            <subtask id="30533">NEUTRON-187</subtask>
                            <subtask id="30534">NEUTRON-188</subtask>
                            <subtask id="30535">NEUTRON-189</subtask>
                            <subtask id="30536">NEUTRON-190</subtask>
                            <subtask id="30537">NEUTRON-191</subtask>
                            <subtask id="30538">NEUTRON-192</subtask>
                            <subtask id="30539">NEUTRON-193</subtask>
                            <subtask id="30540">NEUTRON-194</subtask>
                            <subtask id="30551">NEUTRON-195</subtask>
                    </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_10002" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>NETVIRT-996</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i03cov:</customfieldvalue>

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