parallel-ssh | PSSH provides parallel versions of OpenSSH and related tools | Architecture library

try to put sudo=True at the end of run_command

It could happen if you did not enable alpha feature-gate for the option.

Did you set --feature-gates option for kube-apiserver?

Some explanations which I got from Panos in Google Groups thread. It didn't help me, but maybe it will be helpful for somebody else.

A -5 error is defined as a key exchange error in libssh2. It sounds like the key type is not supported by libssh2 and paramiko shows 'ecdsakey.py' being used. ECDSA keys are not currently supported by libssh2 (PR pending).

The warning are from paramiko itself, can't say if they matter.

Better exceptions for native client errors are being worked on for next release.

_

So for a private key 'my_pkey', there should be a 'my_pkey.pub' in same directory.

It may also be a case of the SSH server's key not being supported by the native client (same limitations as user keys) which would explain the key exchange error. Can check the type of key configured for the server in /etc/ssh/sshd_config, HostKey entry. There should be at least one non-ECDSA key configured, eg:

HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key

If there is only a ECDSA key entry, the native client will not be able to connect.

You could do something like this (thanks @JohnKugelman for the useful tips):

By default Cassandra takes a snapshot whenever a column family is dropped. This is by design to protect accidental truncation (deletion of all records in a table) or accidental drop of that table. The parameter in Cassandra.yaml controlling this is auto_snapshot

Whether or not a snapshot is taken of the data before keyspace truncation or dropping of column families. The STRONGLY advised default of true should be used to provide data safety. If you set this flag to false, you will lose data on truncation or drop. auto_snapshot: true

So based on the screenshot you have shown, looks like the "events" table was dropped atleast 4 times and recreated. So the proper way to clean this up would be to first figure out the correct UUID used by Cassandra for a given table in keyspace. In your case, the query would be

From docs -

parallel-ssh uses gevent’s monkey patching to enable asynchronous use of the Python standard library’s network I/O.

Make sure that ParallelSSH imports come before any other imports in your code. Otherwise, patching may not be done before the standard library is loaded which will then cause ParallelSSH to block.

If you are seeing messages like This operation would block forever, this is the cause.

Monkey patching is only done for the clients under pssh.pssh_client and pssh.ssh_client for parallel and single host clients respectively.

New native library based clients under pssh.pssh2_client and pssh.ssh2_client do not perform monkey patching and are an option if monkey patching is not suitable. These clients will become the default in a future major release - 2.0.0.

Since monkey patching is used for the client you are using, other uses of the threading, socket etc modules in your application will also have been patched to use gevent which means they no longer run in a native thread but in a co-routine/greenlet.

This is the reason your background thread operations block as they run in a greenlet on the same thread rather than a new thread.

As of 1.2.0, a new client based on libssh2 instead of paramiko is available which does not use monkey patching:

I think you're just using the wrong syntax for the ParallelSSHClient constructor, which expects a list of hosts, not a single hostname. (It's fine for the list to have just one item.)

Here's some code I ran based on the examples in the usage guide: