Operating System: All
Platform: All

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.

503 reflect the status of the resource: it is not available.

> 503 reflect the status of the resource:

Do you mean "404"?

> it is not available.

Do you mean "not found"?

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.

Sorry, my mistage, I misunderstood the headline.

Iaroslav notified me the current behavior is status code 409 Conflict, with:
"error-type": "protocol"
"error-tag":"data-missing"
"error-message":Mount point does not exist."

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:

Hmm, 4xx codes look better than 5xx codes, as it is (presumably) not ODL's fault the device is not connected yet.
Looking at https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
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.
Maybe 404 is the best fit from the available codes, as the mount point is not created yet, so it is not found.
A compromise could be to keep 404, but change error-message to "Device not connected." or similar.
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.

vrpolak,

As I see in code: org/opendaylight/restconf/common/errors/RestconfError.java:115

This status code 409 was decided to use instead of 404 during discussions here: NETCONF-682. And it is general behavior of restconf. 

Also it is deprecated API. So I would prefer to leave as it.

Any way, according to existing code you can switch 409 to 404 by setting this property: org.opendaylight.restconf.eid5565

> org/opendaylight/restconf/common/errors/RestconfError.java:115

Thanks for the pointer. Based on that, I can restate my intent:
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).

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.

In request terms this maps most closely towards 502/504: we are 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.