| 2013-08-23 14:22:40 |
Nick Moffitt |
bug |
|
|
added bug |
| 2013-08-23 14:25:28 |
Nick Moffitt |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2013-08-23 14:27:46 |
Matthew Wedgwood |
juju-core: status |
New |
Confirmed |
|
| 2013-08-29 11:26:01 |
Nick Moffitt |
description |
After installing juju-core on a precise server in a private MAAS environment in a highly sensitive network, bootstrap failed in the following manner:
2013-08-23 13:36:57 INFO juju tools.go:25 environs: reading tools with major version 1
2013-08-23 13:36:57 INFO juju tools.go:29 environs: falling back to public bucket
2013-08-23 13:36:57 INFO juju.environs.sync sync.go:69 listing available tools listing available tools
2013-08-23 13:38:01 ERROR juju supercommand.go:274 command failed: Get https://juju-dist.s3.a mazonaws.com/: dial tcp 72.21.195.15:443: connection timed out
error: Get https://juju-dist.s3.amazonaws.com/: dial tcp 72.21.195.15:443: connection timed out
This is correct behaviour, due to the egress filtering required by this network.
I had to look around to find out that I needed to use the --upload-tools parameter to get it to use my local copy of the binary. Since I was using the packaged version of juju-core, my intention to use that specific version of the juju tools should have been obvious.
Could the default (at least for the packaged version) be changed not to download untested versions off the Internet? |
After installing juju-core on a precise server in a private MAAS environment in a highly sensitive network, bootstrap failed in the following manner:
2013-08-23 13:36:57 INFO juju tools.go:25 environs: reading tools with major version 1
2013-08-23 13:36:57 INFO juju tools.go:29 environs: falling back to public bucket
2013-08-23 13:36:57 INFO juju.environs.sync sync.go:69 listing available tools listing available tools
2013-08-23 13:38:01 ERROR juju supercommand.go:274 command failed: Get https://juju-dist.s3.amazonaws.com/: dial tcp 72.21.195.15:443: connection timed out
error: Get https://juju-dist.s3.amazonaws.com/: dial tcp 72.21.195.15:443: connection timed out
This is correct behaviour, due to the egress filtering required by this network.
I had to look around to find out that I needed to use the --upload-tools parameter to get it to use my local copy of the binary. Since I was using the packaged version of juju-core, my intention to use that specific version of the juju tools should have been obvious.
Could the default (at least for the packaged version) be changed not to download untested versions off the Internet? |
|
| 2013-08-30 01:14:06 |
Ian Booth |
juju-core: importance |
Undecided |
Critical |
|
| 2013-08-30 01:14:13 |
Ian Booth |
juju-core: status |
Confirmed |
Triaged |
|
| 2013-09-25 22:50:01 |
Curtis Hovey |
juju-core: importance |
Critical |
High |
|
| 2013-10-01 16:54:53 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2013-10-01 16:56:37 |
David Britton |
tags |
|
theme-oil |
|
| 2013-10-12 04:25:47 |
Curtis Hovey |
tags |
theme-oil |
firewall theme-oil |
|
| 2013-10-12 04:25:54 |
Curtis Hovey |
tags |
firewall theme-oil |
firewall maas theme-oil |
|
| 2013-10-14 20:22:23 |
Curtis Hovey |
tags |
firewall maas theme-oil |
boostrap firewall maas theme-oil |
|
| 2013-10-17 15:06:39 |
Curtis Hovey |
tags |
boostrap firewall maas theme-oil |
bootstrap firewall maas theme-oil |
|
| 2014-02-28 04:34:57 |
Dave Cheney |
tags |
bootstrap firewall maas theme-oil |
bootstrap firewall maas ppc64el theme-oil |
|
| 2014-03-13 18:33:52 |
Mark Ramm |
bug |
|
|
added subscriber Mark Ramm |
| 2014-03-17 21:18:33 |
Mark Ramm |
juju-core: milestone |
|
1.20.0 |
|
| 2014-05-12 14:34:57 |
Canonical Juju QA Bot |
juju-core: milestone |
1.20.0 |
next-stable |
|
| 2014-05-12 19:09:09 |
Curtis Hovey |
juju-core: milestone |
next-stable |
|
|
| 2014-05-12 19:14:37 |
Curtis Hovey |
juju-core: importance |
High |
Medium |
|
| 2014-05-14 03:13:36 |
Curtis Hovey |
juju-core: status |
Triaged |
Fix Released |
|
