Issue with bootstrap image

Dear community,
We operate a cloud infrastructure where we maintain a library with various preinstalled images with Linux/Unix. We are currently working to provide an Ubuntu installation with JUJU.
In the process, we are getting an error which halts the progress.

After issuing the command:

juju bootstrap cloudsigma --debug

we get this output:

17:02:08 ERROR juju.cmd.juju.commands bootstrap.go:697 failed to bootstrap model: cannot start bootstrap instance: failed start instance: Failed to query drive template: 401 None
17:02:08 DEBUG juju.cmd.juju.commands bootstrap.go:698 (error details: [{/build/juju/parts/juju/go/src/github.com/juju/juju/cmd/juju/commands/bootstrap.go:772: failed to bootstrap model} {/build/juju/parts/juju/go/src/github.com/juju/juju/environs/bootstrap/bootstrap.go:562: } {/build/juju/parts/juju/go/src/github.com/juju/juju/environs/bootstrap/bootstrap.go:471: } {/build/juju/parts/juju/go/src/github.com/juju/juju/provider/common/bootstrap.go:56: } {/build/juju/parts/juju/go/src/github.com/juju/juju/provider/common/bootstrap.go:212: cannot start bootstrap instance} {/build/juju/parts/juju/go/src/github.com/juju/juju/provider/cloudsigma/environinstance.go:81: failed start instance: Failed to query drive template: 401 None}])
17:02:08 DEBUG juju.cmd.juju.commands bootstrap.go:1332 cleaning up after failed bootstrap
17:02:08 INFO  juju.provider.common destroy.go:21 destroying model "controller"
17:02:08 INFO  juju.provider.common destroy.go:32 destroying instances
17:02:08 ERROR juju.cmd.juju.commands bootstrap.go:1334 error cleaning up: destroying instances: 400 Bad Request
17:02:09 INFO  cmd supercommand.go:502 command finished

Can we get some advice as to what is causing this behavior, and perhaps what we can do differently? Thanks in advance!

Thanks for reaching out. Let me look into it. The team’s currently traveling back from a work sprint so might be a slight delay but we’ll get some help your way.

Thank you, @rick_h,

We are looking forward to hearing from you!

Below you can find a output of which juju:

root@Mk:/home/cloudsigma# which juju
/snap/bin/juju

Also, we have a library with pre-installed images, where we have a drive with installed Juju on it. However, we are still getting the error “Failed to query drive template: 401 None”. Could you please help us to resolve this?

In doing some checking it looks like we’ve stopped publishing images for cloudsigma some time ago. We might need to go back in time to find an image to use.

Can you try using a constraint to try to get a 14.04 or 16.04 image?

juju bootstrap --bootstrap-series=trusty
juju bootstrap --bootstrap-series=xenial

In looking at the code we attempt to request a new instance from the cloud but are getting back that error.

I’m not certain if the cloudsigma apis have moved and the Juju code hasn’t adapted or not. Let’s start with trying to check for images and then we can see where it leads from there.

Dear @rick_h,

Thank you for your assistance!

We installed Juju on an image with Ubuntu 16.04, then we added it to our library in the Manila location. After that, we executed the command juju bootstrap cloudsigma --debug and this time the error was different:

20:40:13 INFO  juju.environs.bootstrap tools.go:74 found 15 packaged agent binaries
20:40:13 INFO  cmd bootstrap.go:389 Starting new instance for initial controller
20:40:15 INFO  cmd bootstrap.go:151 Launching controller instance(s) on cloudsigma/hnl...
20:40:15 INFO  juju.provider.cloudsigma environinstance.go:42 sigmaEnviron.StartInstance...
20:40:15 ERROR juju.cmd.juju.commands bootstrap.go:528 failed to bootstrap model: cannot start bootstrap instance: no matching image meta data
20:40:15 DEBUG juju.cmd.juju.commands bootstrap.go:529 (error details: [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:620: failed to bootstrap model} {github.com/juju/juju/provider/common/bootstrap.go:50: } {github.com/juju/juju/provider/common/bootstrap.go:202: cannot start bootstrap instance} {github.com/juju/juju/provider/cloudsigma/environinstance.go:26: no matching image meta data}])
20:40:15 DEBUG juju.cmd.juju.commands bootstrap.go:1126 cleaning up after failed bootstrap
20:40:15 INFO  juju.provider.common destroy.go:20 destroying model "controller"
20:40:15 INFO  juju.provider.common destroy.go:31 destroying instances
20:40:15 ERROR juju.cmd.juju.commands bootstrap.go:1128 error cleaning up: destroying instances: 400 Bad Request
20:40:15 INFO  cmd supercommand.go:465 command finished

As you can see, we are no longer getting the error “Failed to query drive template: 401 None”, but it is replaced with “cannot start bootstrap instance: no matching image metadata”.

Any advice would be appreciated!

Thanks for the heads up. So i think the issue here is that we’re getting closer but Juju can’t find information for the instances to identify which image it should bring up for Juju.

If you look at the released streams for the cloud here:
http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:cloudsigma.json

There’s only two instance ids. I’m not sure if they’re still valid but I assume the one that Juju is getting told to use isn’t in that list and so we can’t identify it or something along those lines. Someone more familiar with the instance there might have a better clue.

I’ve not used this personally but there’s some dev tools around this that might be useful to try to get it going. See:

Hello @rick_h,

Apologies for the delay with the replay.

We still have the issue described above. Could you please let us know how to add more released streams for the cloud?

We are looking forward to hearing from you.

If you want an experimental way to use images not yet in stream metadata, you can turn on a feature flag. The official image metadata is still the best choice when available.

export JUJU_DEV_FEATURE_FLAGS=image-metadata
bootstrap --bootstrap-image=deadbeaf --bootstrap-series=bionic --bootstrap-constraints="arch=amd64" ...

Note: you need to specify series and arch as well since there’s no metadata with this information.
Obviously substitute real values for the sample data above.

You also have access to additional commands:

juju metadata list-images
juju metadata add-image
juju metadata delete-image

As stated above, this feature is behind a feature flag so needs to be considered experimental, but hopefully will unblock you.