local provider behaves poorly when juju-mongodb is not installed on trusty

[Tycho Andersen]

When juju-mongodb is not installed on trusty, no error is given about the missing binary. Juju doesn't seem to notice. It still tries to connect to it.

nxjmh:~ juju bootstrap
uploading tools for series [trusty precise]
Logging to /home/ubuntu/.juju/local/cloud-init-output.log on remote host
Starting MongoDB server (juju-db-ubuntu-local)
Bootstrapping Juju machine agent
^CInterrupt signalled: waiting for bootstrap to exit
a929963f886b5acf391d246683312e087048563fbfa05f0d6ab2a14684179ca5 /home/ubuntu/.juju/local/tools/1.17.7.1-trusty-amd64/tools.tar.gz
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00232358 s, 451 MB/s
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00174232 s, 602 MB/s
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0010311 s, 1.0 GB/s
juju-db-ubuntu-local start/running, process 2513
2014-04-02 18:25:30 INFO juju.cmd supercommand.go:297 running juju-1.17.7.1-trusty-amd64 [gc]
2014-04-02 18:25:30 DEBUG juju.agent agent.go:384 read agent config, format "1.18"
2014-04-02 18:25:30 DEBUG juju.agent bootstrap.go:63 initializing address [localhost:37017]
2014-04-02 18:25:30 INFO juju.state open.go:81 opening state; mongo addresses: ["localhost:37017"]; entity ""
2014-04-02 18:25:30 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
...
2014-04-02 18:27:35 DEBUG juju.state open.go:101 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
Bootstrap failed, destroying environment
ERROR exit status 1
nxjmh:~ 1 cat ~/.juju/environments.yaml
default: local

environments:
  local:
    type: local
    container: kvm
nxjmh:~ juju --version
1.17.7-trusty-amd64
nxjmh:~ cat /etc/issue
Ubuntu Trusty Tahr (development branch) \n \l

this happens with both kvm and lxc backing the local provider.

[Curtis Hovey (sinzui)]

I think the solution is for juju to check if the juju-local package is installed. Abort when it is not. This ensures users don't try to think about the deps. Too many users think they know what juju requires.

[John A Meinel (jameinel)]

I'm pretty sure this is now fixed, as CI does regular testing of local
bootstrap.

Curtis, can you confirm? (Is Trusty local bootstrap a regular CI test?)

On Wed, Apr 2, 2014 at 10:34 PM, Curtis Hovey <email address hidden> wrote:

> ** Description changed:
>
> nxjmh:~ juju bootstrap
> uploading tools for series [trusty precise]
> Logging to /home/ubuntu/.juju/local/cloud-init-output.log on remote host
> Starting MongoDB server (juju-db-ubuntu-local)
> Bootstrapping Juju machine agent
> ^CInterrupt signalled: waiting for bootstrap to exit
> a929963f886b5acf391d246683312e087048563fbfa05f0d6ab2a14684179ca5
> /home/ubuntu/.juju/local/tools/1.17.7.1-trusty-amd64/tools.tar.gz
> 1+0 records in
> 1+0 records out
> 1048576 bytes (1.0 MB) copied, 0.00232358 s, 451 MB/s
> 1+0 records in
> 1+0 records out
> 1048576 bytes (1.0 MB) copied, 0.00174232 s, 602 MB/s
> 1+0 records in
> 1+0 records out
> 1048576 bytes (1.0 MB) copied, 0.0010311 s, 1.0 GB/s
> juju-db-ubuntu-local start/running, process 2513
> 2014-04-02 18:25:30 INFO juju.cmd supercommand.go:297 running
> juju-1.17.7.1-trusty-amd64 [gc]
> 2014-04-02 18:25:30 DEBUG juju.agent agent.go:384 read agent config,
> format "1.18"
> 2014-04-02 18:25:30 DEBUG juju.agent bootstrap.go:63 initializing
> address [localhost:37017]
> 2014-04-02 18:25:30 INFO juju.state open.go:81 opening state; mongo
> addresses: ["localhost:37017"]; entity ""
> 2014-04-02 18:25:30 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:30 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:30 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:31 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:31 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:31 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:32 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:32 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:33 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:33 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:33 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:34 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:34 DEBUG juju.state open.go:101 connection failed, will
> retry: dial tcp 127.0.0.1:37017: connection refused
> - 2014-04-02 18:25:34 DEBUG juju.state open.go:101 c...

[John A Meinel (jameinel)]

Given the behavior is still wrong in the 1.18 series in Trusty (bug #1311016) we may want to backport this fix.