netconf-connector readiness test suite.

Copyright (c) 2015,2016 Cisco Systems, Inc. and others. All rights reserved.

This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html

Try to detect whether Netconf is up and running and wait for it for a configurable time if it is not yet up and running.

This is achieved by the test Check_Whether_Netconf_Topology_Is_Ready. This test case does not use controller-config device. This test case is skipped (Pass Execution) if the usage of controller-config device is indicated. Testing itself is done by creating a netconf test device configured to all odl nodes one by one and check if GET works from mounted device. GET is done from all the odl nodes and it works for both, 1 or 3 nodes setup.

The next test cases are basically dedicated to test readiness of the netconf using controller-config device. This device is created when odl-netconf-connector-ssh|all feature is installed. Robot variable USE_NETCONF_CONNECTOR should be set to True. Connector test cases change behavior depending on False. If True, they check data mounted behind controller-config is readable, if False they only check topology-netconf is readable.

Some testsuites expect netconf-connector to be ready as soon as possible and will fail if it is not. We want to see a failure if this is the cause of the failure.

The usage of netconf-connector happens in other suites than netconf, especially bgpcep to configure odl's bgp peers. Testing the readiness of the netconf-connector must be invoked by the Robot invocation argument USE_NETCONF_CONNECTOR. By default it is set to False and test jobs should be responsible to set it to True if needed. In the default configuration the affected test cases waits for the netconf topology to appear only.

If the netconf-connector is not ready upon startup and it's usage is set to True (as seen by the second test case failing), the next case starts to repeat the query for a minute to see whether it is going "to fix itself" within the minute. If yes, then the testcase will pass, which indicates that the "ODL cooldown" of 1 minute is not long enough to allow for netconf-connector to initialize properly. If this fails, one more check with even longer timeout is run. If the Check_Whether_Netconf_Is_Up_And_Running pass, then the next test case does nothing.

The other test case then checks whether Netconf can pretty print data. This sometimes makes problems, most likely due to too new Robot Requests library with an interface incompatible with this test suite.