juju run fails on manually provisioned instance

[Tom Haddon]

We have an environment running in OpenStack that has some MAAS deployed machines that have been added via manual provisioning. We're able to do pretty much any operation on the instances in the environment, with the exception of juju run:

$ juju run --unit ubuntu/0 "uname -a"
Linux juju-prodstack-database-machine-0 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Warning: Permanently added '10.35.24.22' (ECDSA) to the list of known hosts.
$ juju run --unit postgresql/0 "uname -a"
ssh: connect to host 10.22.96.32 port 22: Connection timed out
ERROR rc: 255
$ juju ssh postgresql/0 "uname -a"
Linux myhostname 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Connection to myhostname.internal closed.

Here we see that juju run works on the ubuntu/0 unit (an OpenStack instance), but fails on postgresql/0 (a manually provisioned instance). However, juju ssh works fine on postgresql/0

I've since discovered https://jujucharms.com/docs/1.20/config-manual which says: "It is possible to manually provision machines into non-manual provider environments, however the machine must be placed on the same private subnet as the other machines in the environment."

In our case, the OpenStack subnet is 10.35.24.0/22 but the manually provisioned instance is on a 10.22.96.x subnet. Are there simply firewall rules we need to ensure are in place so that the instances can reach each other in some way to be able to do a juju run?

[Curtis Hovey (sinzui)]

This issue relates to bug 1429790. In general, ssh to manually provided machines is dodgy.

[Curtis Hovey (sinzui)]

Oops, wrong bug ^ I meant bug 1340133 is about ssh failing to manually added instances.

[Tom Haddon (mthaddon)]

I realise this may not be the issue you meant, but I looked at bug 1429790 and saw that it was fixed by installing tmux on the instance in question. I can confirm that we have tmux installed on both the server we're deploying from and the manually provisioned instance.