The SingleInstanceTask does not allow us to control cancellation the way
we want. We now use a standard asyncio.Task to execute the coroutine
that fetches the list of snaps.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The list snaps task used to return successfully even in case of error.
To make the distinction between and error and a successful fetch, we
used to rely on the task to set an attribute at the loader level:
* failed = True; or
* failed = False
The task was responsible for setting this attribute and there were
scenarios where it would not set the attribute properly. Usually, this
was when an exception was raised in the task.
We now raise an exception when an error occurs in the task ; instead of
returning. This is better because we can know if the task:
* got cancelled - by calling "task.cancelled()"
* finished successfully - by calling "task.done() and not
task.exception()"
* failed - by calling "task.done() and task.exception()"
* has not finished - by calling "not task.done()"
This also allows us to detect errors and retry
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Once we have access to the list of snaps, we can start prefetching
information. We need to wait for the list snaps task to be completed
first.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The --cloud-config option now replaces the old --autoinstall-file
option.
The use of --autoinstall-file always made kvm-test pass the autoinstall
argument to the kernel command line. With the --cloud-config option, we
now determine if the autoinstall argument is needed by reading the cloud
config and checking if an autoinstall section is present.
The two new options --force-autoinstall and --force-no-autoinstall can
be used to override this behaviour.
The --autoinstall option is also dropped. If we want to use the default,
hardcoded cloud-config, one can use --cloud-config-default.
This can be useful to ease debugging of the VM using a config that looks
like:
#cloud-config
users:
- default
- name: root
ssh_import_id: lp:ogayot
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Until recently, subiquity and curtin had shared ownership regarding
mounting/unmounting the cdrom to/from the target:
* curtin was responsible for bind-mounting /cdrom to /target/cdrom
* subiquity was responsible for unmounting /target/cdrom
We recently made subiquity responsible for bind-mounting the cdrom to
the target too, which is a good thing.
Unfortunately, we now attempt to unmount the cdrom from the target
twice, at the end of the installation:
* once because we explicitly unmount the cdrom from the target before
restoring the APT config on target
* once because subiquity has a mechanism that automatically unmount
everything that it mounted, in reverse order.
This leads to a crash at the end of the installation.
Fix this issue by making sure we only try to unmount the cdrom once. If
we unmount it before restoring the APT config, then we don't want to
unmount it automatically anymore.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Where we don't have a proper snapd support.
Approach similar to the one used in UDI.
For the case where we have Subiquity snap, but not UDI.
The script added is a stripped version of the UDI one.
Removed code related to:
- GTK and GDK;
- GI repository;
- Xkb;
Preserved:
- Python;
- XDG directory definitions;
- font config;
When a client sends a GET /snaplist request and an error occurs on the
server side, we return a response of the following form:
{ "status": "FAILED", ... }
This effectively gives a chance to the client to retry the same request
and expect a different outcome (for instance when a temporary network
failure occurs).
Having said that, when the server returns "status": "FAILED", it also
automatically marks the snaplist model configured. This is wrong because
if the next GET /snaplist request succeeds, the user will be prompted to
select some snaps to install ; but the installation will already be
running in the background. Depending on the timing, it might or might
not install the snaps that the user selected.
Fixed by not marking the snaplist model configured automatically. The
client is made responsible from sending a POST /snaplist ; even in case
of error.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
I've wanted to do this for ages and getting ready to talk to the snapd
API provided an excuse :-) (as, for example, to get info about a snap
you talk to the /v2/snaps/{snap_name} endpoint). As before, the server
part isn't strictly needed but I forgot about that and actually
implemented it first. Oh well, we'll need it if I implement my idea
described in a comment in apidef.py to make the network API more RESTish.
The snapd API does not JSON-encode query arguments, they are just all
strings. I only need the client side of this really but implementing it
server side might avoid confusion down the road.
Similarly to field names, the snapd API returns objects with values that
should be part of an enumeration, but with values that are not all
Python identifiers (e.g. "system-seed"). To allow these to be mapped to
enum's in Python that are not insanely annoying to use, allow a
Serializer to serialize enum's to and from their values rather than
their names (which remains the default behaviour).
Many snapd APIs return JSON objects with field names that are not valid
Python identifiers (such as "display-name") so if we're going to
translate them to and from Python objects we need to be able to override
the field name in the serialized form.
Some snapd APIs return JSON objects with lots and lots of fields and I
don't want to have to declare the ones I am not interested in. Also, I
think snapd adds fields over time, so I don't want to be broken when
this happens.
to the WSLSetupOptions controller.
Misuse of the default_loader().
That's meant for loading /etc/wsl.conf.
WSLSetupOptions is by design not related to that config file.
When editing a LVM logical volume (LV), Subiquity would crash with the
following error:
filesystem/gaps.py", line 244, in movable_trailing_partitions_and_gap_size
pgs = parts_and_gaps(partition.device)
AttributeError: 'LVM_LogicalVolume' object has no attribute 'device'
When we changed the implementation to use
movable_trailing_partitions_and_gap_size, we did not pay attention to
the LVM use case.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The mirror controller is responsible from creating the APT configuration
once its associated model is marked configured. However, the APT
configuration is also dependent on the source model being marked
configured.
When subiquity is used for the server installer, the client immediately
sends a POST /a/meta/client_variant request. This ends up marking the
source model as configured (even though the default value does not make
much sense). So we never end up in a scenario where the mirror model is
marked configured before the source model.
When Subiquity is used by a different client, such as the
ubuntu-desktop-installer, it is possible that we mark the mirror model
configured first. This ends up crashing the installer.
Fixed by adding a dependency on the source model so that we do not end
up creating the APT configuration too early.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Olivier Gayot