boot-images reports images, but pxe boot fails with no-such-image

[Andreas Hasenack]

maas 1.8.0+bzr4001-0ubuntu2~trusty1 from http://ppa.launchpad.net/maas-maintainers/stable/ubuntu/

We have a scripted install of MAAS where we use the API to have MAAS import images. Once they are imported, we kick off a VM to PXE boot. That VM fails with an error about not finding the image (screenshot attached).

Our script loops over a "maas admin boot-images read <cluster-uuid> call" while that returns an empty list.

2015-08-05 12:54:01,709 DEBUG CMD: ['maas', 'admin', 'boot-images', 'read', 'a29c9361-20a7-40cb-9048-4c4053a2196d']
2015-08-05 12:54:01,966 DEBUG STDOUT:
[]

(...)
2015-08-05 12:56:16,889 DEBUG CMD: ['maas', 'admin', 'boot-images', 'read', 'a29c9361-20a7-40cb-9048-4c4053a2196d']
2015-08-05 12:56:17,152 DEBUG STDOUT:
[
    {
        "subarchitecture": "hwe-u",
        "osystem": "ubuntu",
        "label": "release",
        "architecture": "amd64",
        "release": "trusty",
        "purpose": "co(mmissioning"
    },
....
(http://pastebin.ubuntu.com/12006850/ for full list)

As soon as it returns a list of images, we kick off the VM. This fails randomly with the error from the screenshot.

We now added a sleep(120) before we kick off the VM and right after boot-images returned a list of images. So far it has been working.

Detailed logs are available in the private bug #1481488, I can't sanitize those right now.

[Andres Rodriguez (andreserl)]

Andreas,

Also, why are we trying to use utopic instead of generic?

"subarchitecture": "hwe-u", - > utopic hwe kernel?

[Andreas Hasenack (ahasenack)]

Hm, it just "came with it", we didn't select utopic.

[Lee Trager (ltrager)]

Could you please attach the script you are using?

[Andreas Hasenack (ahasenack)]

Here is the script log. Look for 'maas', 'admin' for the parts where we issue API calls, and the corresponding output will be just below.

[Andreas Hasenack (ahasenack)]

Here are full logs (pod installer and maas) of a run that worked, but with the sleep(120). That sleep kicks in between these two log lines in the pod log:

2015-08-05 12:56:17,153 DEBUG Found boot images: trusty:hwe-u, ...
(sleep 120s)
2015-08-05 12:58:17,254 INFO Done importing MAAS boot resources

In the previous log we didn't have this sleep.

[Lee Trager (ltrager)]

I've been unable to reproduce this bug on MAAS 1.8.0

[Adam Collard (adam-collard)]

What do you need us to provide? Please don't mark bugs as Incomplete without a specific request for information (that you are unable to ascertain yourself)

[Andreas Hasenack (ahasenack)]

Since we are still seeing this, another workaround we will add now after the sleep(120) is to restart maas-clusterd.

[Andres Rodriguez (andreserl)]

We believe that this is not longer an issue in the latest releases of MAAS. If you believe this is still an issue, please re-open this bug report and target it accordingly.