Comment 4 for bug 1242476

If this is a private cloud with custom images, what needs to be available for bootstrap to succeed is simplestreams metadata describing what image id to use for a particular series/arch. Separate to that, additional simplestreams metadata is used to locate a tools tarball to use.

The upload-tools process generates the tools metadata and tools tarball and uploads to the Openstack cloud storage (aka control bucket). The various tools index metadata files included with this bug report are correct - they are a red herring. Index metadata file do not require any cloud records be defined - if there are none, then it is expected a simple product file be used and any cloud filtering will be done using the product data. If no tools can be found, an error would have occurred and bootstrap would have aborted.

The DefaultIndexPath is correct - "streams/v1/index". The search path includes "<control_bucket>/tools" so the index path is relative to the tools container.

The other "not found" log items refer to the fact that signed metadata files (ending with .sjson) cannot be found. This is to be expected because only official metadata produced by Canonical for certifified public clouds is currently signed.

The other metadata is index metadata and this is what the error is complaining about. Unless I have missed it, I can't see this image metadata index file attached to the bug report. I am assuming the image meatdata has been uploaded to the control bucket - like for tools, this is in the search path for locating image ids. In 1.16, the image metadata is placed in a folder "<control_bucket>/streams/v1". The next Juju release it will be "<control_bucket>/images/streams/v1"

My guess is that the image metadata is wrong. In Juju 1.16, the image metadata generation tool is still more of a developer prototype rather than an end user tool, but the steps are essentially:

1. juju metadata generate-image -i <imageid> -d <local_dir>
2. upload contents of local_dir to control bucket

See juju help metadata generate-image for more info.

Without additional params, generate-image takes region, series, endpoint, arch from the current environment. The region/endpoint form the cloud specification and this is what is placed in the image index file. This not matching is what the error in the bug report is about.