| Age | Commit message (Collapse) | Author |
|---|
|
ct_netconfc:init_per_suite called ct_test_support:init_per_suite
before checking if crypto exists. This caused the slave node (ct@host)
to be started even though the suite would be skipped when crypto did
not exist - which in turn caused a hanging ct node since end_per_suite
is not run in a skipped suite. This has been corrected.
|
|
OTP-10510
When starting a named netconf connection directly after stopping one
with the same name, it sometimes failed with 'connection_exists'. This
has been corrected.
|
|
|
|
|
|
Earlier, it was possible to open connection (ct_gen_conn) with the
same (required) name twice, which could give unexpected results. Such
attempts will now return {error,{connection_exists,OtherClient}}.
|
|
Earlier ct_util_server would terminate and thus abort the complete
test run if a connection process (ct_gen_conn) crashed. This is now
changed so that ct_util will only print an error report (in the test
case log) and continue the rest of the test.
|
|
The netconf client supports basic netconf functionality over SSH. In
order to allow testing of both success and failure cases, it is
intentionally written to allow non-standard behavior.
In order for the netconf client to use the generic connection
mechanism in common_test, ct_gen_conn has been updated to be more
flexible:
Added options:
{reconnect,bool()}
{forward_messages,bool()}
{use_existing_connection,bool()}
Allow handle_msg to return
{reply,Reply,State} |
{noreply,State} |
{stop,Reply,State}
If forward_messages==true, the ct_gen_conn callback must also
implement:
handle_msgs(Msg,State) -> {noreply,State} | {stop,State}
|
