Using clush on nonexistent node with option "--remote=no" leads to local execution

[AdrienDebrie]

ClusterShell 1.7.1 When using "--remote=no", a clush command does not fail when a target node is not reachable. Instead, the action is performed locally:

[root@madmin0 (ROME) ~]# ping toto
ping: unknown host toto
[root@madmin0 (ROME) ~]# cat /tmp/topology-test.conf 
[Main]
madmin0: gidc1
gidc1: rome[6-10]
[root@madmin0 (ROME) ~]# clush --topology=/tmp/topology-test.conf --remote=no -w rome6 hostname
rome6: gidc1.bullx
[root@madmin0 (ROME) ~]# clush --topology=/tmp/topology-test.conf --remote=no -w toto hostname
toto: madmin0.bullx

We usually get a legitimate error when we try to contact a node that isn't reachable/doesn't exist:

[root@madmin0 (ROME) ~]# clush -w toto hostname
toto: ssh: Could not resolve hostname toto: Temporary failure in name resolution
clush: toto: exited with exit code 255
[root@madmin0 (ROME) ~]# clush --topology=/tmp/topology-test.conf -w toto hostname
toto: ssh: Could not resolve hostname toto: Temporary failure in name resolution
clush: toto: exited with exit code 255

[degremont]

There is no bug here. When a node does not exist in topology, it is considered as being directly reachable. It does not require a gateway. This is expected and very convenient.

In your example, toto is unknown, so it should be reachable directly from madmin0. As you specified remote=no commands are run localy. That means:

• hostname on gidc1.bullx
• hostname on madmin0

[thiell]

I agree with @degremont, this is not a bug but a feature 😄 However, I understand your problem here and I also noticed this "disturbing" behavior a few times. What about a flag to enforce the use of tree mode, eg. forbid running it on targets that are "out of scope"?

[degremont]

Let's make this "feature" tunable :)

[thiell]

Indeed, if we figure out how to implement this, we could start to add a library default tunable (topology_mode: strict or something like that). Other ideas welcomed, but that's not before 1.8.