As part of our integrations tests, we import mwhudson's public SSH
key(s) from GitHub. At the moment, however, the GitHub API is rate
limiting the number of queries from our CI.
Upon exceeding the rate limit, our HTTP queries are responded with a 403:
┌────────────────────────────────────────────────────────────────────────┐
│ Importing keys failed: │
│ │
│ 2023-01-08 23:43:40,562 ERROR GitHub REST API rate-limited this IP │
│ address. See https://developer.github.com/v3/#rate-limiting . │
│ status_code=403 user=mwhudson │
└────────────────────────────────────────────────────────────────────────┘
Currently, upon pushing to GitHub, the CI runs the integrations tests
against 4 different Ubuntu images (focal, jammy, kinetic, lunar).
This ends up doing 4 SSH import queries at roughly the same time ; which
often exceeds the rate limit and makes some of the tests fail.
This patch makes integration tests import SSH keys from Launchpad
instead of GitHub. Maybe a better approach would be to mock the calls to
ssh-import-id in the CI instead.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Instead of defining a ContinueAnyway widget specific to Ubuntu Pro, we
now lean on the new ConfirmationOverlay to obtain the same result.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The new ConfirmationOverlay object along with the
BaseView.ask_confirmation helper can be used to open a confirmation
dialog and get back the decision from the user.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Specifying the value of subprocess.PIPE as the stdin argument of
astart_command did not have any effect. This happened because the
parameter was not forwarded to the subprocess function. The parameter
was effectively unused.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
That variant would only apply configs if in autoinstall.
There are no more screens available related to those settings in
wsl_setup.
Reconfiguration variant is the only one able to write that file.
Once we do this, there is no reason to use the 'python' plugin, so
switch to the 'nil' plugin with an override-build that calls pip for
each of the subiquity, curtin, and probert parts.
Follow guidance from PEP 632 and move some of this over to setuputils.
build.build lacks a straightforward answer, use the vendored copy of
distutils found in setuptools but delaying the import until after
setuptools.
Cancelling the installer self refresh does not work. Clicking on the
button simply goes back to the screen asking the user if they want to
update ; but the refresh operation still continues in the background.
Since we do not have a simple way to implement refresh cancellation at
the moment, we are just removing the button.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
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>
Olivier Gayot