cannot bootstrap azure because no OS image found

[Curtis Hovey]

Bootstrap fails on azure using 1.15.0 fails

2013-10-02 01:19:28 DEBUG juju.environs.simplestreams simplestreams.go:433 read metadata index at "http://cloud-images.ubuntu.com/daily/streams/v1/index.sjson"
2013-10-02 01:19:28 DEBUG juju.environs.simplestreams simplestreams.go:441 index file has no data for product name(s) ["com.ubuntu.cloud:server:12.04:amd64" "com.ubuntu.cloud:server:12.04:i386"]
2013-10-02 01:19:44 ERROR juju supercommand.go:282 cannot start bootstrap instance: no OS images found for location "West US", series "precise", architectures ["amd64" "i386"] (and endpoint: "https://management.core.windows.net/")

The azure provider is looking for cloud images at http://cloud-images.ubuntu.com/daily/streams/v1/index.sjson and does not find a match. Instead of checking "releases", it bails. I would expect Azure to look at several places for cloud images. I am surprised daily is the first place it looks.

The workaround is to use image-metadata-url to point Juju to a good set of cloud simple streams.
    image-metadata-url: http://cloud-images.ubuntu.com/releases

[Andrew Wilkins (axwalk)]

I've found the offending code, just writing a test for it now.

[Andrew Wilkins (axwalk)]

So jam just raised a good point about why it might be the way it is (i.e. it might be intentional): if you have a private cloud, then you might populate metadata into your private bucket. If it finds the metadata, but it doesn't include what they've asked for, does it make sense to go to the public cloud?

We will just take out the default daily stream for now, and people can add it in their environments.yaml if they really want it.

[John A Meinel (jameinel)]

So the code in question *does* have multiple search locations, but we ended up with a bit of split-brain.

The highest level loop says:
  for source in sources:
     try to get signed data
     if there was a problem:
       try to get unsigned data
    if there wasn't an error:
      break
Which is, essentially, reach each location until you don't get an error.

However for Azure one of the locations that was injected was the "daily" stream. However if you aren't using the daily images, then there are no "released" images in that stream.

The currently logic is designed such that once we find a valid simplestreams we stop looking at fallbacks. This is possibly valid in the case of users uploading their own custom images. (eg I want you to use my special image, and just fail if you can't) vs (eg I want you to use my custom images for precise-amd64, but use the generic ones for saucy-i386)

Right now, injecting a valid stream into the search path is intentionally preventing fallbacks from being used.
However, we can just remove the daily stream from the Azure search path. Users that really need it can set image-stream: daily and imagemetadata-url: http://cloud-images.ubuntu.com/daily and it should still work for them.