1.21 alpha dumps a stack trace when ec2 credentials are missing
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| juju-core |
Fix Released
|
High
|
Unassigned | ||
Bug Description
Created a fresh ec2 instance of 14.04 and installed juju from the devel PPA to get 1.21-alpha1 to test out as I was asked to set up a demo next week using juju 1.21.
So I installed juju:
ubuntu@
ii juju 1.21-alpha1-
ii juju-core 1.21-alpha1-
Then edited environments. yaml to add my AWS api key and add the devel tools stream pointer that is mentioned on the devel ppa page:
amazon:
type: ec2
# region specifies the EC2 region. It defaults to us-east-1.
#
# region: us-east-1
# access-key holds the EC2 access key. It defaults to the
# environment variable AWS_ACCESS_KEY_ID.
#
# access-key:
# secret-key holds the EC2 secret key. It defaults to the
# environment variable AWS_SECRET_
#
secret-key: MY_SECRET_
# image-stream chooses a simplestreams stream to select OS images
# from, for example daily or released images (or any other stream
# available on simplestreams).
#
# image-stream: "released"
# Whether or not to refresh the list of available updates for an
# OS. The default option of true is recommended for use in
# production systems, but disabling this can speed up local
# deployments for development or testing.
#
# enable-
# Whether or not to perform OS upgrades when machines are
# provisioned. The default option of true is recommended for use
# in production systems, but disabling this can speed up local
# deployments for development or testing.
#
# enable-os-upgrade: true
Then I attempted a bootstrap and the following is what happened:
ubuntu@
2014-10-14 21:28:11 INFO juju.cmd supercommand.go:37 running juju [1.21-alpha1-
2014-10-14 21:28:11 INFO juju.provider.ec2 ec2.go:216 opening environment "amazon"
2014-10-14 21:28:11 INFO juju.cmd cmd.go:113 Bootstrap failed, destroying environment
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x40 pc=0x4e0957]
goroutine 1 [running]:
runtime.
/usr/lib/
github.
/build/
main.destroyPre
/build/
main.func·020()
/build/
main.func·018()
/build/
main.(*
/build/
github.
/build/
main.(*
/build/
github.
/build/
github.
/build/
main.Main(
/build/
main.main()
/build/
goroutine 3 [syscall]:
os/signal.loop()
/usr/lib/
created by os/signal.init·1
/usr/lib/
goroutine 8 [finalizer wait]:
runtime.
/usr/lib/
runfinq()
/usr/lib/
runtime.goexit()
/usr/lib/
The instance is a standard m1.tiny aws instance running 14.04.1:
ubuntu@
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
| Jeff Lane (bladernr) wrote | #1 |
| Changed in juju-core: | |
| importance: | Undecided → Critical |
| status: | New → Triaged |
| milestone: | none → 1.21-alpha2 |
| Changed in juju-core: | |
| importance: | Critical → High |
| summary: |
- 1.21 alpha on trusty dumps a stack trace when trying to bootstrap + 1.21 alpha dumps a stack trace when ec2 credentials are missing |
| tags: | added: config ec2-provider ui |
| Ian Booth (wallyworld) wrote | #2 |
| Changed in juju-core: | |
| status: | Triaged → Fix Committed |
| Changed in juju-core: | |
| status: | Fix Committed → Fix Released |
Ok, found the issue. I backed down to 1.18 on trusty. According to the documentation on setting up aws:
"All you need to do to get this configuration to work is to either set the AWS_ACCESS_KEY_ID and AWS_SECRET_
in environments.yaml above note that I was ONLY setting secret_key.
I tried with 1.18 setting AWS_SECRET_
ubuntu@
ubuntu@
ubuntu@
ERROR environment has no access-key or secret-key
I retried using only secret-key in environments.yaml and got the same error. Finally, I filled in BOTH access-key and secret-key in envionrments and was able to bootstrap 1.18.
So with that, I removed 1.18 and re-installed 1.21 and using both access-key and secret-key in the environments.yaml file, I was able to successfully start a bootstrap with 1.21.
So first issue, the docs and boilerplate environments.yaml need to be fixed to say you need BOTH secret-key and access-key to bootstrap ec2. (it would also help to add info on using IAM as that's Amazon's recommended way of using api access now).
Second issue, however, is the stack dump that occurs on 1.21 when the bootstrap fails.
Third issue, on 1.21 there was no error telling me WHY bootstrap failed. With 1.18 the message pointed me in the right directly, if not necessarily completely accurate. But on 1.21 there is no such message before the stacktrace is dumped on teardown.