Do I need to put image metadata in a private bucket?

Question

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
auth-url: http://173.23.181.5:5000/v2.0
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?

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.