=== CyberJacob is now known as CyberJacob|Away === smoser` is now known as smoser === CyberJacob|Away is now known as CyberJacob [19:39] Hi, I'm trying to bootstrap a manual env but it fails to configure Juju machine agent [19:39] this is the output I get: http://pastebin.com/tZ2sQErt [19:39] any idea ? [19:41] juju 1.20.13-trusty-amd64 [19:42] destination is a trusty vm as well === erkules_ is now known as erkules [22:05] now I have bootstraped the env but running juju status fails [22:05] 2014-11-30 20:50:41 DEBUG juju.state.api apiclient.go:248 error dialing "wss://juju:17070/", will retry: websocket.Dial wss://juju:17070/: dial tcp 130.211.X.X:17070: connection refused [22:18] that url looks wrong [22:18] Tug_: bootstrapped what type of environment... with what config? [22:19] thumper, manual env with very simple config [22:19] bootstrap-host: juju [22:19] the rest is default [22:20] hmm... [22:20] is the "juju" host the same as the machine you are running on? [22:20] or a different one? [22:20] a different one [22:20] actually I just tried something interesting [22:21] is it actually running? [22:21] I installed juju-core on the machine agent [22:21] and set up the same config and it worked [22:21] it shouldn't need that [22:21] so something looks wrong [22:22] it looks like the port is closed maybe ? [22:22] can you uninstall juju-core and look again? [22:22] on my machine ? [22:22] you can ssh to the machine and look in /etc/init to see if the jobs are registered [22:22] no, the fact that it failed before, then you installed juju-core on the other machine then it worked [22:22] could be a missing dependency [22:22] what version ? [22:23] I mean it worked when I run juju status from the machine agent [22:23] not from my machine [22:23] 1.20.13-trusty-amd64 [22:24] oh [22:24] perhaps it is just a problem resolving 'juju' ? [22:24] I still get "connection refused" from my machine [22:25] yeah that's what I was thinking [22:25] you can try this... [22:25] but it does resolve to 130.211.X.X [22:25] it is a hack mind [22:25] which is correct [22:25] and then the port is open [22:25] I think [22:26] well if it works on that machine, but not from your client [22:26] I'd double check that the port is open [22:26] can you telnet to it? [22:26] telnet: Unable to connect to remote host: Connection refused [22:26] nop [22:27] check your settings :-) [22:27] yeah it must be that :) [22:27] but sadly it's all set [22:28] (it's just a network config on google compute engine) [22:28] http://ifjfij.appspot.com/i?b=fe584c4a904d35cc52a5d807a46f6d3413f27308 [22:29] * thumper shrugs [22:39] at least I excluded juju from the cause :) [22:40] yeah, there is that [22:47] or it could be... here is what I have with netstat [22:48] tcp6 0 0 :::17070 :::* LISTEN 17596/jujud [22:48] maybe juju does not forward ipv4 connections === mjs0 is now known as menn0 [22:58] fyi, it was a bug in google cloud (for real) removing the rule and recreating it did the trick :)