Comment 3 for bug 1271744

Hi Curtis,

I understand that I might be doing something wrong while reproducing the environment and that's ok. I'm still learning to debug juju failures. I did download the tools again every time I tried to reproduce the environment and verified the checksum of the downloaded tarball and the checksum generated by the `metadata generate-tools` command and they were always different.
The downloaded tarball had this hash: 3c3c04ec40c2f52d1e5f9fa356825c91ce9bbfce92b4142e44827f32d8289753 while the `metadata generate-tools` command had b16e15764b8bc06c5c3f9f19bc8b99fa48e7894aa5a6ccdad65da49bbf564793. Is it possible that the `metadata generate-tools` is actually hashing some other tarball than the one in the directory passed via -d option? Ok, I just confirmed your suggestion of using the absolute paths, and got the 3c3c04ec40c2f52d1e5f9fa356825c91ce9bbfce92b4142e44827f32d8289753 hash for the tool in the juju-metadata dir.

In any case, I think there are a couple of bugs here:

1. Juju bootstrap --debug doesn't output the whole cloud-init-output.log from the bootstrapped node, which makes debugging a lot harder, since juju stops the instance on failure.
2. I think would be nice to have an option to tell juju to not stop the instance in case of failure so one can do some analysis of what went wrong during its initialization
3. The `metadata generate-tools` -d option doesn't work correctly with relative paths.

Hope this helps.