quickstart should detect private clouds somehow and generate metadata url in the environments.yaml
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | juju-quickstart |
High
|
Unassigned | ||
Bug Description
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://
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:/
UX can be improved immensely in those cases.
| Changed in juju-quickstart: | |
| status: | New → Confirmed |
| Changed in juju-quickstart: | |
| status: | Confirmed → Triaged |
| importance: | Undecided → High |
| Dimiter Naydenov (dimitern) wrote : | #1 |
| Dimiter Naydenov (dimitern) wrote : | #2 |
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) wrote : | #3 |
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://
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.
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:/
image-metadata-url: http://
(for 1.21+)
agent-metadata-url: https:/
image-metadata-url: http://
Then quickstart can run $ juju metadata validate-tools and $ juju metadata validate-images to ensure those will work before attempting to bootstrap.