Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

network: fix Wi-Fi interfaces not listed in dry-run #1785

Merged
merged 2 commits into from
Sep 7, 2023

Conversation

ogayot
Copy link
Member

@ogayot ogayot commented Sep 4, 2023

When a Wi-Fi interface is present in the machine configuration (e.g., mwhudson.json), the GUI seemingly ignores it. This happens because there is a filter on the server side which only returns Wi-Fi interfaces if the wlan_support_install_state() function returns
PackageInstallState.DONE.

However, calling the /network endpoint shows that the state is set to the wrong value:

 {"wlan_support_install_state": "NOT_NEEDED"}

This turns out to be inconsistent because:

  • we lean on a PackageInstaller instance to tell if wpasupplicant is installed (this is what the wlan_support_install_state() function reflects) ; but
  • in dry-run mode, we pretend to install wpasupplicant without actually relying on the PackageInstaller instance.

Fixed by using the PackageInstaller instance to install the wpasupplicant package - with a special implementation that only pretends to install it. This is enough to make the PackageInstaller instance think the package is installed.

LP: #2039091

When a Wi-Fi interface is present in the machine configuration (e.g.,
mwhudson.json), the GUI seemingly ignores it. This happens because there
is a filter on the server side which only returns Wi-Fi interfaces if
the wlan_support_install_state() function returns
PackageInstallState.DONE.

However, calling the /network endpoint shows that the state is set to
the wrong value:

 {"wlan_support_install_state": "NOT_NEEDED"}

This turns out to be inconsistent because:
 * we lean on a PackageInstaller instance to tell if wpasupplicant is
installed (this is what the wlan_support_install_state() function
reflects) ; but
 * in dry-run mode, we pretend to install wpasupplicant without
actually relying on the PackageInstaller instance.

Fixed by using the PackageInstaller instance to install the
wpasupplicant package - with a special implementation that only pretends
to install it. This is enough to make the PackageInstaller instance
think the package is installed.

Signed-off-by: Olivier Gayot <[email protected]>
Copy link
Collaborator

@mwhudson mwhudson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, but I think I would rather have a DryRunPackageInstaller class, like we do for CommandRunner. In fact, if we change PackageInstaller to use app.command_runner can we delete a bunch of code??

@ogayot
Copy link
Member Author

ogayot commented Sep 5, 2023

Thanks for this, but I think I would rather have a DryRunPackageInstaller class, like we do for CommandRunner. In fact, if we change PackageInstaller to use app.command_runner can we delete a bunch of code??

Updated. I must admit I don't find these DryRun classes very practical. But I do like that it makes the "main" code cleaner (less cluttered with dry-run specific things).

I had to introduce a little bit of code duplication here, hope it's okay..

Copy link
Collaborator

@mwhudson mwhudson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for not reviewing yesterday, I did read the code but somehow forgot to write anything down!

This looks OK. I don't think we have to regard the interpretation of SUBIQUITY_DEBUG_FLAGS with any kind of stability though -- seems like it would make things easier and more flexible to switch to using some syntax like SUBIQUITY_DEBUG_FLAGS=pkginstall=wpasupplicant=FAILED or something?

@ogayot
Copy link
Member Author

ogayot commented Sep 7, 2023

Sorry for not reviewing yesterday, I did read the code but somehow forgot to write anything down!

This looks OK. I don't think we have to regard the interpretation of SUBIQUITY_DEBUG_FLAGS with any kind of stability though -- seems like it would make things easier and more flexible to switch to using some syntax like SUBIQUITY_DEBUG_FLAGS=pkginstall=wpasupplicant=FAILED or something?

Yes that sounds like good improvements to implement going forward :)

@ogayot ogayot merged commit bb50ee9 into canonical:main Sep 7, 2023
10 checks passed
@ogayot ogayot deleted the wifi-package-not-needed branch September 7, 2023 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants