quickstart should detect private clouds somehow and generate metadata url in the environments.yaml

[Dimiter Naydenov]

A new user (Muntaner) reported on #juju an error while trying to use juju-quickstart to deploy an environment from one laptop onto another one in the same LAN - the latter laptop has OpenStack devstack deployed. Here's the initial log: http://paste.ubuntu.com/9760532/ and the environments.yaml: http://paste.ubuntu.com/9760545/

It seems because this is a private openstack installation, bootstrap fails due to not finding simplestreams metadata.

Ideally, quickstart should try to detect such a scenario and try to generate a working config.

Some ideas on how this can be detected (not actually tried, just thinking out loud): if the provider type is maas or openstack and there are local (RFC 1918) IPs specified in auth/server URLs, either try running sync-tools before bootstrap, alternatively try the trick Curtis suggested recently - set tools-metadata-url: https://streams.canonical.com/juju/tools (for 1.20x) or agent-metadata-url: https://streams.canonical.com/juju/tools.

UX can be improved immensely in those cases.

[Dimiter Naydenov (dimitern)]

Following an ad-hoc troubleshooting session on #juju. So far it seems the easiest workaround is to add these lines in the generated environments.yaml:

(for 1.20x)
tools-metadata-url: https://streams.canonical.com/juju/tools
image-metadata-url: http://cloud-images.ubuntu.com/releases

(for 1.21+)
agent-metadata-url: https://streams.canonical.com/juju/tools
image-metadata-url: http://cloud-images.ubuntu.com/releases

Then quickstart can run $ juju metadata validate-tools and $ juju metadata validate-images to ensure those will work before attempting to bootstrap.

[Dimiter Naydenov (dimitern)]

I might be wrong about image-metadata-url though, as in a private cloud scenario we need (in addition to setting tools-metadata-url) to run $ juju metadata generate-images -d <path>, then $ juju metadata validate-images -d <path>, and finally $ juju bootstrap --metadata-source <path>.

[Dimiter Naydenov (dimitern)]

Correction - comment #2 - "generate-image" not "generate-images". Also the image id (-i <id>) argument is required, so the the user needs to know how to create/list created images via the cloud API in order to use it.

A nice article I found with detailed instructions: http://blog.felipe-alfaro.com/2014/04/29/bootstraping-juju-on-top-of-an-openstack-private-cloud/

In summary, it does not seem as easy as I thought originally to automate this process with juju-quickstart.
It's still useful though, but likely lower priority.