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.
Upon reaching the Ubuntu Pro screen that shows the user-code, we need to
initiate a contract selection. If we are navigating to the screen a
second time though, we need to cancel existing contract selections
before initiating a new one.
Failing to do so results in a UPCSAlreadyInitiatedError.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In dry-run mode, instead of reading the uacontracts environment URL from
/etc/ubuntu-advantage/uaclient.conf, we can now override this variable
by specifying the 'pro_ua_contracts_url' dry-run parameter.
In conjunction with 'pro_magic_attach_run_locally', this allows us to
test Subiquity against testing environments. By default it will use the
staging environment (i.e., https://contracts.staging.canonical.com).
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In dry-run mode, the 'magic_attach_run_locally' variable can now be used
to execute uaclient on the host (against the uacontracts environment
specified in /etc/ubuntu-advantage/uaclient.conf) instead of relying on
a mock mechanism.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>