https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-341 netconf <p>Currently the returned status code is 404, which callers might understand as a confirmation that the resource is not present in the mounted datastore. But the resource might be in fact present in the datastore, just ODL cannot access the datastore this time.</p> <p>This distinction is important for CSIT to distinguish transient instability (for example in cluster High Availability testing) from really missing data.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-341

Return status code 503 instead of 404 when a mountpoint is not mounted

Bug Resolved Done Iaroslav Kholiavko Vratko Polak Tue, 24 Jan 2017 13:25:48 +0000 Sun, 21 Feb 2021 11:28:39 +0000 Sun, 21 Feb 2021 11:28:39 +0000 1.13.0 restconf-nb 0 5 <p>I don't think there's any way to distinguish between these 2 cases. From restconf POV the mountpoint either is in the MountPointService or it's not. There's no way to tell whether some southbound plugin is configured to connect to a device and the mountpoint is temporarily unavailable.</p> <p>503 reflect the status of the resource: it is not available.</p> <p>&gt; 503 reflect the status of the resource:</p> <p>Do you mean "404"?</p> <p>&gt; it is not available.</p> <p>Do you mean "not found"?</p> <p>I would understand if ODL removed the mountpoint when there is a problem accessing it (so 404 will be correct as the device is no longer mounted), but that was not what was happening in cluster tests, if I recall correctly.</p> <p>Sorry, my mistage, I misunderstood the headline.</p> <p>Iaroslav notified me the current behavior is status code 409 Conflict, with:<br/> "error-type": "protocol"<br/> "error-tag":"data-missing"<br/> "error-message":Mount point does not exist."</p> <p>Here is my response, which I started to writes as a personal message, but then decided to put is here so it is tracked properly:</p> <p>Hmm, 4xx codes look better than 5xx codes, as it is (presumably) not ODL's fault the device is not connected yet.<br/> Looking at <a href="https://en.wikipedia.org/wiki/List_of_HTTP_status_codes" class="external-link" target="_blank" rel="nofollow noopener">https://en.wikipedia.org/wiki/List_of_HTTP_status_codes</a><br/> I see "404 Not Found" and "410 Gone", but in this situations we could use a code that says something like "Not Arrived Yet". I think "409 Conflict" does not really reflect the situation.<br/> Maybe 404 is the best fit from the available codes, as the mount point is not created yet, so it is not found.<br/> A compromise could be to keep 404, but change error-message to "Device not connected." or similar.<br/> Mainly because 503 refers to the state of the whole service (in this case restconf or netconf), so users may get a wrong impression. Especially non-human ones that do not comprehend error-message.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vrpolak" class="user-hover" rel="vrpolak">vrpolak</a>,</p> <p>As I see in code: org/opendaylight/restconf/common/errors/RestconfError.java:115</p> <p>This status code 409 was decided to use instead of 404 during discussions here: <a href="https://jira.opendaylight.org/browse/NETCONF-682" title="RFC8040 compliance - wrong URI returns incorrect HTTP status" class="issue-link" data-issue-key="NETCONF-682"><del>NETCONF-682</del></a>. And it is general behavior of restconf. </p> <p>Also it is deprecated API. So I would prefer to leave as it.</p> <p> </p> <p>Any way, according to existing code you can switch 409 to 404 by setting this property: org.opendaylight.restconf.eid5565</p> <p> </p> <p>&gt; org/opendaylight/restconf/common/errors/RestconfError.java:115</p> <p>Thanks for the pointer. Based on that, I can restate my intent:<br/> When a mountpoint is not mounted (but the corresponding device is configured, just not connected for whatever reason), the ErrorTag value should be RESOURCE_DENIED_TRANSPORT (not DATA_MISSING).</p> <p>Ah, but RESTCONF obviously has no knowledge of how mountpoints come into existence, nor should it have – it can be SNMP, NETCONF, all sorts of implementations. It is just not feasible to understand that difference, as it implies a monolithic system.</p> <p>In request terms this maps most closely towards 502/504: we <b>are</b> acting as a proxy, but we did not even attempt to contact the upstream server. Hence I think RESOURCE_DENIED_TRANSPORT is correct in the specific case of the mount point not being found.</p> Development External issue ID 7668 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01xxz: