<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:14:45 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>[NETCONF-340] After killing device owner, there is a period of 404.</title>
                <link>https://jira.opendaylight.org/browse/NETCONF-340</link>
                <project id="10142" key="NETCONF">netconf</project>
                    <description>&lt;p&gt;Status 404 means a resource is currently missing, but it is not clear whether this should cover cases when the connection to the device is temporarily down, or whether 503 should be reported for those cases.&lt;br/&gt;
Doubly so if the fluctuation of the connectivity is not caused by the device or the network, but by a failed (killed) ODL cluster member.&lt;/p&gt;

&lt;p&gt;If 404 is to be expected, it should be documented and the suites updated. The rest of this description assumes Restconf user should not see 404.&lt;/p&gt;

&lt;p&gt;This issue is seen in Carbon (both &lt;del&gt;only&lt;/del&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; and &lt;del&gt;all&lt;/del&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;) and Boron (&lt;del&gt;only&lt;/del&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;, &lt;del&gt;all&lt;/del&gt; is not stable enough), and it might be timing dependent (currently CSIT is spending 10 second in futile wait for Karaf SSH response when logging start of a test case, the timeout is needed to avoid &lt;a href=&quot;https://jira.opendaylight.org/browse/ODLPARENT-49&quot; title=&quot;Karaf ssh EOFError (is it due to low entropy, due to Java&amp;#39;s default use of blocking /dev/random instead of /dev/urandom?)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;ODLPARENT-49&quot;&gt;&lt;del&gt;ODLPARENT-49&lt;/del&gt;&lt;/a&gt; symptom in the first few test cases).&lt;/p&gt;

&lt;p&gt;In each case there is an election for new owner and reconnect happening in the karaf.log &lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; but time synchronization is not precise enough to determine the exact time 404 was generated. The Boron log &lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; contains long segment (between 2017-01-22 20:05:10,931 and 2017-01-22 20:05:14,521) which seem to be relevant.&lt;/p&gt;

&lt;p&gt;Presumably, there is a period of time (before the new owner successfully connects to the device) where status is &quot;connecting&quot;, so there is nothing mounted, so 404 may be expected. Except that users have no way to detect both connection status and access the resource at the same instant, so currently they are whether 404 means &quot;it is not there&quot; or &quot;we do not know right now&quot;.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-carbon/399/archives/log.html.gz#s1-s6-t17-k2-k2-k2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-carbon/399/archives/log.html.gz#s1-s6-t17-k2-k2-k2&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/160/archives/log.html.gz#s1-s6-t12-k2-k1-k3-k6&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/160/archives/log.html.gz#s1-s6-t12-k2-k1-k3-k6&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-boron/736/archives/log.html.gz#s1-s6-t17-k2-k2-k2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-boron/736/archives/log.html.gz#s1-s6-t17-k2-k2-k2&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-carbon/399/archives/odl1_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-carbon/399/archives/odl1_karaf.log.gz&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/160/archives/odl3_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/160/archives/odl3_karaf.log.gz&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-boron/736/archives/odl1_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-boron/736/archives/odl1_karaf.log.gz&lt;/a&gt;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="21353">NETCONF-340</key>
            <summary>After killing device owner, there is a period of 404.</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="10001">Won&apos;t Do</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="vrpolak">Vratko Polak</reporter>
                        <labels>
                    </labels>
                <created>Mon, 23 Jan 2017 14:54:48 +0000</created>
                <updated>Fri, 15 Mar 2019 22:22:34 +0000</updated>
                            <resolved>Mon, 27 Aug 2018 21:36:11 +0000</resolved>
                                                                    <component>restconf-nb</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="39782" author="vrpolak" created="Tue, 24 Jan 2017 13:31:05 +0000"  >&lt;p&gt;The two solutions to this Bug which would help with CSIT:&lt;/p&gt;

&lt;p&gt;1. Return HTTP status code 503 so that the client know it should retry the request later.&lt;/p&gt;

&lt;p&gt;2. Make the Restconf request block while owner is connecting or not elected yet.&lt;/p&gt;

&lt;p&gt;There are also hybrid solutions is possible, for example blocking for some time, but returning 503 if the time expires.&lt;/p&gt;

&lt;p&gt;I just realized that the owner election is just one of possible reasons why a device could be not mounted, so I have opened &lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt; as a Restconf Change request.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://bugs.opendaylight.org/show_bug.cgi?id=7668&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://bugs.opendaylight.org/show_bug.cgi?id=7668&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="39783" author="tcere" created="Thu, 12 Oct 2017 11:25:13 +0000"  >&lt;p&gt;As I said in 7668, there is no way for restconf to distinguish whether the device is reconnecting/temporarily unavailable or just not present at all, since it only has access to MountPointService which only sais whether a MountPoint for a certain Identifier is present or not.&lt;br/&gt;
When you kill a device owner, temporary unavailability is expected until the southbound plugin recovers and selects a new leader, but I dont think theres a way to change the status code with the information available to Restconf.&lt;/p&gt;</comment>
                            <comment id="64799" author="rovarga" created="Mon, 27 Aug 2018 21:36:11 +0000"  >&lt;p&gt;This is an implication of how RPC registration propagate, this works as designed (eventual consistency).&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>7661</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=7661]]></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="10349"><![CDATA[Unspecified]]></customfieldvalue>

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

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