gthouenon orenais FYI

We have to ensure that:

1. when we are below max_attempts the device status is connecting
2. when we are exceeding max_attempts the device status is unable-to-connect
3. when device is turned off and on again we need to ensure transition from connecting to connected
4. when device is turned off and on again we need to ensure that device stays in unable-to-connect

All these requirements are satisfied in 5.0.x branch.

The option #3 can be tested when running testool (which automatically creates 17830-sim-device) and simultaneously creating another topology node, for example test-device with the same configuration as 17830-sim-device.

Now, after turning off and on testtool we are getting incorrect response:

GET http://192.168.56.25:8181/rests/data/network-topology:network-topology/topology=topology-netconf?fields=node/node-id;node/netconf-node-topology:connection-status

{
    "network-topology:topology": [
        {
            "node": [
                {
                    "node-id": "17830-sim-device",
                    "netconf-node-topology:connection-status": "connected"
                },
                {
                    "node-id": "test-device",
                    "netconf-node-topology:connection-status": "unable-to-connect"
                }
            ]
        }
    ]
}

We expect both devices to be connected. Assuming the devices max_attempt to reconnect are not exceeded.

...

"netconf-node-topology:max-connection-attempts": 0

...

is used to set unlimited connection attempts.

Ready for review, to p[prevent further occurrences of similar issues we will create unit tests in NETCONF-1119.

This issue shows that we are quite lacking in terms of API definition. The callbacks in RemoteDeviceHandler have no attached meaning, but implementation experience shows there is an implicit lifecycle contract expressed therein.