Confusing status when starting radssh

[stuartort]

[[A[vagrant@hpcc1 ~]$ python -m radssh.shell 10.239.190.1-106
*** 2 plugin(s) failed to load. ***
Use --verbose=on option to see details.
10.239.190.1-106 expanded by ip
Connecting to 106 hosts...
[STALLED] Waiting on 106 of 106 results
[STALLED] Waiting on 106 of 106 results
[STALLED] Waiting on 106 of 106 results
.....................................................................................................XXXXX
RadSSH $

Then I did an ls and got 5 errors
Summary of failures:
None - [IPAddress('10.239.190.34'), IPAddress('10.239.190.45'), IPAddress('10.239.190.54'), IPAddress('10.239.190.64'), IPAddress('10.239.190.71')]
Average completion time for 101 hosts: 2.977918s
RadSSH $

I thought the ....XXXX matched the IPS and not just a count

[radssh]

The shorthand connection status characters are documented here: http://radssh.readthedocs.org/en/v1.0.1/shell_quickstart.html#starting-up-a-shell-session. Each . indicates a successfully established and authenticated connection, and each X indicates a network related failure to connect. Not seen in your example is O, which would indicate that a network connection was successfully made, but there was a failure in authenticating the user login session.

You can display status details on all connections (successful or not), using the *info command. This will automatically be invoked at the conclusion of the cluster connection attempts, if your configuration option verbose is set to on.

When invoking commands, RadSSH will skip the attempt to run commands on any session connection that is either unauthenticated or not connected. Since the command is not run, there can be no exit status, and the failure summary will group such connections with a return status of 'None', rather than an integer status code for executed commands.

In the event that there are any failed connections or failed authentications encountered during the initial connections, a message summarizing the counts of each type of failure, and a reminder that *info can be used to show details would help significantly to clear up confusion when these types of errors occur.

Keeping issue open as enhancement to add user message(s) when cluster is not 100% connected/authenticated.

[stuartort]

Ok. I had thought the each . X or O indicated the status of each node, so that if I had ..X then node 3 would have not connected. That is what I was commenting about

[radssh]

The connection attempts are made in parallel by the same thread pool that RadSSH command execution uses, so the connection status codes are emitted in the order of completion, not in the order of submission. Will update the documentation to spell this out more clearly. I still like the idea of the summary messages mentioned above, even if that was not your original source of confusion.

[radssh]

Released in https://github.com/radssh/radssh/tree/v1.0.5