After killing device owner, there is a period of 404.

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.
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.

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.

This issue is seen in Carbon (both only [0] and all [1]) and Boron (only [2], all 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 ODLPARENT-49 symptom in the first few test cases).

In each case there is an election for new owner and reconnect happening in the karaf.log [3] [4] [5] but time synchronization is not precise enough to determine the exact time 404 was generated. The Boron log [5] contains long segment (between 2017-01-22 20:05:10,931 and 2017-01-22 20:05:14,521) which seem to be relevant.

Presumably, there is a period of time (before the new owner successfully connects to the device) where status is "connecting", 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 "it is not there" or "we do not know right now".

[0] https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-carbon/399/archives/log.html.gz#s1-s6-t17-k2-k2-k2
[1] https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/160/archives/log.html.gz#s1-s6-t12-k2-k1-k3-k6
[2] https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-boron/736/archives/log.html.gz#s1-s6-t17-k2-k2-k2
[3] https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-carbon/399/archives/odl1_karaf.log.gz
[4] https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/160/archives/odl3_karaf.log.gz
[5] https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-only-boron/736/archives/odl1_karaf.log.gz