I'm experimenting using Juju (16.6) to deploy services to our private Openstack cloud and have noticed a couple of issues.

When bootstrapping a new environment, Juju apparently wants to look in the environment's bucket for image metadata. I've created a "public" bucket, using Swift for the object store, and populated it with the image meta-data in "streams/v1/*" object paths - however when bootstrapping juju fails unless the meta-data is in the environment's private bucket. Is this normal? And is there a work around in the environment's config to fix this problem?

My environment is as follows (less ssh keys):

access-key: ""
admin-secret: ""
agent-version: 1.16.6
api-port: 17070
auth-mode: userpass
authorized-keys: 'ssh-rsa `...
ca-private-key: ""
control-bucket: juju-bucket
default-image-id: ""
default-instance-type: ""
default-series: precise
development: false
firewall-mode: instance
image-metadata-url: ""
logging-config: <root>=INFO
name: openstack-ws
password: xxxxxxxxxx
public-bucket: juju-dist
public-bucket-url: ""
region: regionOne
secret-key: ""
ssl-hostname-verification: true
state-port: 37017
tenant-name: WebServices
tools-url: ""
type: openstack
use-floating-ip: true
username: xxxxx

Once I get the environment to bootstrap, I next try to bring up a service. In my case, I'm using the Hadoop charm. When I deploy the hadoop master (juju deploy hadoop hadoop-master), the instance fails to initialize with a "hostname: name or service not known error". I suspect this is due to failure of a reverse DNS lookup on the instances "public" IP address. Does this sound correct? What is the issue?

  • Can you please include you full log of the juju bootstrap --debug --show-log command? You can use paste.ubuntu.com and add a link here (redacting any secrets before that of course).
    – dimitern
    Feb 21, 2014 at 11:43

1 Answer 1


Both public-bucket and public-bucket-url settings were deprecated some time ago and are ignored. Only the control-bucket is used, if specified - otherwise it's randomly generated. The private bucket is now the only way to override fetching juju tools with a specified version from simplestreams data.

For example, running juju bootstrap --upload-tools after ensuring you ran the equivalent of:

# cd $GOPATH/src/launchpad.net/juju-core/cmd/juju # go install . # cd ../jujud # go install .

packages the juju binaries (juju and jujud) from $PATH into a release tarball and uploads it to the control-bucket. Then, cloud-init script runs when the bootstrap machine boots, downloading and installing the most recent current tools (which--upload-tools always ensures). So juju bootstrap --upload-tools, if hacky it's certainly useful to test changes to the juju-core source in an actual deployment.

Alternatively, you could run:

juju sync-tools --all --public --source=~/.juju/local/storage/tools/release/

right after running juju bootstrap -e local --upload-tools (assuming you've run the 2 go install commands mentioned earlier, when building from source). That way, you'll need to run juju bootstrap -e local and observe the progress/check the logs.

  • I was able to bootstrap by mucking with the control bucket in Swift - populating the streams/v1 object paths with my local image metadata. So the problem I have with bootstrapping is where does the local private cloud image metadata belong? In the local/storage/tools/release directory? The node that I'm able to bootstrap is then, however, unable to startup additional instances. Is this due to DNS entries for public IP addresses not being present?
    – skibum
    Feb 25, 2014 at 22:38
  • Running juju sync-tools as described in the answer should fix your bootstrap and instance startup issues.
    – dimitern
    Feb 25, 2014 at 23:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.