MAAS deletes image architectures if you delete all images of that architecture

Bug #1969510 reported by Andre Ruiz
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Triaged
Low
Unassigned
3.4
Won't Fix
Low
Unassigned
maas (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

If you try to import a custom image in maas cli it fails with a cryptic error which turns out to be because of a non-existing architecture.

Upon further investigation, it seems that if you delete all images of a specific architecture the architecture itself disappears and then you cannot add a custom image of that arquitecture again, it will fail.

Workaround is to go back to the images section in the GUI, select some ubuntu image of that architecture, wait for it to download and then re-try adding the custom image which will then work.

This is very non-intuitive for end users, and also it's possible for an airgapped environment to erase all images and then get into a situation where they cannot recover.

My understanding (based on conversations on maas channel) is that this is a known behavior, which makes this is bug report a feature-request to 'fix' this to work in a more intuitive way.

Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

Added project MAAS (previously it was only under ubuntu package maas).

description: updated
description: updated
Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

Ways to reproduce:

This WORKS:

1) Install a fresh maas.
2) Download any ubuntu image of x86_64 architecture using GUI
3) Manually add a custom x86_64 image via CLI (say, for example, ESXi)
4) Check it was correctly added as a custom image and is available on the images list when deploying

This does NOT work:

1) Install a fresh maas
2) Download any ubuntu image of x86_64 architecture using GUI (you need to download at least one when installing).
3) Go back to images menu and delete all images of x86_64 architecture (including ubuntu ones)
4) Manually add a custom x86_64 image via CLI (again, for example, and ESXi image)
5) Watch it fail with a cryptic message about "Wrong architecture"

But this will fix the problem:

6) Go back to images screen, download some x86_64 ubuntu image again
7) Manually add a custom x86_64 image via CLI
8) This time it will work again

Problem is that:

- this is very non-intuitive, specially the error message given
- the proposed fix may not be desirable or even possible (i.e. air gapped systems)

Changed in maas:
status: New → Triaged
Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

MAAS needs Ubuntu images to be able to deploy other distros. This is currently not explicitly indicated in the UI or in the documentation, which leads to possible confusion when the user deletes these images. We will think about ways to remove that confusion, or consider adding a feature to MAAS that explicitly manages ephemeral images.

It would help us to know why the user wants to delete images - would you be able to provide more background, Andre?

Changed in maas:
importance: Undecided → Low
milestone: none → 3.4.0
summary: - MaaS deletes image architectures if you delete all images of that
+ MAAS deletes image architectures if you delete all images of that
architecture
Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

In the case that started this discussion, the client wanted maas just to deploy ESXi images. He's not interested in ubuntu (for that particular maas install). After we made ESXi images work, he redeployed the lab and this time he deleted all ubuntu images since he was not intending to use them. Later, when importing the ESXi ones, he stumbled on this problem and asked for our help to debug it.

I'm sure it was not that important for him to delete ubuntu images and he could have kept them there if needed, but that innocent action made us lose a lot of time debugging and trying to understand why the ESXi images would not import anymore.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in maas (Ubuntu):
status: New → Confirmed
Alberto Donato (ack)
Changed in maas:
milestone: 3.4.0 → 3.4.x
Changed in maas:
milestone: 3.4.x → 3.5.x
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.