Attempting to close an overlay that does not exist is pretty much always
a bug in the code. Making not_found_ok true by default will hide obvious
bugs from us ; which is not a good thing. Perhaps more importantly, we
might just remove the wrong overlay.
Instead, we should just pass not_found_ok=True as a workaround when we
know the code is buggy and don't have time to fix the bug cleanly.
This is what happens for SSH keys import. If the import fails, we remove
the loading animation. However for answers-based runs, we do not have a
loading animation so the code bails. Let's add not_found_ok=True in this
context and we can fix the code later.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
BaseView.remove_overlay() would crash with AttributeError if no overlay
was found. We now add a not_found_ok parameter (defaulting to True) that
makes the function silently return if the overlay could not be found.
Passing not_found_ok=False and catching OverlayNotFoundError can be
helpful in some scenarios to do something different if no overlay was
found.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
I implemented these a long time ago to help working on parts of the ui
by allowing a way to script moving past some screens. I haven't used
them in ages, it's pretty bad code and probably a fragmentary answers
file is a better solution to the same problem. What do you think?
The list of drivers suggested to the user may vary based on whether we
are installing a server or desktop image / source.
In the current implementation of the drivers controller, the value of
the source variant (e.g., server or desktop) is read early in the
initializer.
This is a problem because it happens before the client gets the
opportunity to tell us if we are installing a server or a desktop image.
If the source variant ever changes, we want to query again the list of
drivers to suggest.
Upon configuring the source, the drivers controller will query (again)
the list of drivers.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The drivers controller used to mark the model configured automatically
if no drivers were found. This is okay in most cases but sometimes, we
want to query again the list of drivers (after the client_variant gets
set for instance) and we don't want the model to remain configured.
Let's leave this up to the client to decide if the model should be
configured.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The data passed to on-volumes needs to indicate, for each "structure"
(partition) defined by the gadget the path to the underlying device. The
current code attempts to this by tracking the partition for each role
but this doesn't work: there maybe be more than one partition with no
role. So refactor to have the controller convert the "volume" structure
to an "on-volume" structure early and update the device fields after
curtin runs.
I'm like 99% sure that all call paths to here align the size properly,
apart from the one in apply_system, which I want to be able to create
improperly sized partitions.
If and when the desktop installer adds a snaps screen, we should
probably fetch information for a different set of snaps for a desktop
install. But for now this is OK.
Olivier Gayot