Remove the option to install WSL/HyperV on Windows #25237
Conversation
openshift-ci
bot
added
release-note
approved
|
Ephemeral COPR build failed. @containers/packit-build please check. |
|
Setting |
l0rd
force-pushed
the
stop-automatic-wsl-hyperv-installation
branch
from
37a509c to
247d34f
Compare
|
LGTM |
| WSLCheckbox=${wslCheckboxVar} ` | ||
| HyperVCheckbox=${hypervCheckboxVar} ` |
There was a problem hiding this comment.
If I pass this on the cli will the installer error out?
On the end hand it makes sense so cli users know we removed the feature on the other hand this will beak all scripts who use it.
There was a problem hiding this comment.
It doesn't error out. Microsoft installers ignore parameters that they cannot recognize. That's a bad design for today's standards, but that's how they work. So CLI users won't figure out anything until they run podman machine init. Now, podman machine init can install WSL automatically, which may make things smoother. But there is a bug, and most importantly, there are no CI tests, so these things get broken easily. We may want to talk about that more.
There was a problem hiding this comment.
Yeah I think no error is might better here if we do not want break some scripts, that said they likely find out the hard way if WSL/hyperV is no longer installed.
I guess the only question is if we want to ship "breaking" changes in 5.X or wait until a 6.0. Normally I would be against any breaking changes but this is windows and I don't really care about the installer so if this helps you/us to prevent future problems then I am cool with it.
|
You likely want to close #24881 as wontfix then if we remove the option completely |
| $paths= @( | ||
| # Files generated by the `podman` target | ||
| "$PSScriptRoot\bin\windows" | ||
| # Files generated by the `installer` target | ||
| "$PSScriptRoot\test\version\version.exe" | ||
| "$PSScriptRoot\contrib\win-installer\artifacts" | ||
| "$PSScriptRoot\contrib\win-installer\current" | ||
| "$PSScriptRoot\contrib\win-installer\docs" | ||
| "$PSScriptRoot\contrib\win-installer\en-us" | ||
| "$PSScriptRoot\contrib\win-installer\fetch" | ||
| "$PSScriptRoot\contrib\win-installer\obj" | ||
| "$PSScriptRoot\contrib\win-installer\*.log" | ||
| "$PSScriptRoot\contrib\win-installer\*.exe" | ||
| "$PSScriptRoot\contrib\win-installer\*.wixpdb" | ||
| # Files generated by the Documentation target | ||
| "$PSScriptRoot\docs\build\remote\podman-*.html" | ||
| "$PSScriptRoot\docs\build\remote\podman-for-windows.html" | ||
| ) | ||
|
|
||
| foreach ($path in $paths) { | ||
| if (Test-Path -Path $path -PathType Container) { | ||
| Remove-Item $path -Recurse -Force -Confirm:$false | ||
| } elseif (Test-Path -Path $path -PathType Leaf) { | ||
| Remove-Item $path -Force -Confirm:$false | ||
| } | ||
| } |
There was a problem hiding this comment.
this does not seem related to the installer removal and should be in a separate commit, then I add my LGTM
There was a problem hiding this comment.
Yes, I sneaked this in, but it's not related. I moved it to a separate commit.
Signed-off-by: Mario Loriedo <[email protected]>
The Windows installer was able to automatically enable the Windows features for WSL or HyperV when they were not already enabled. This PR removes this capability. Having the installer to automatically install the right prerequiste (WSL or HyperV) was helpful as users won't have to do it manually to use Podman after the installation. But it also made the code of installer more complicated as it needed to manage the installation of these OS features and a reboot. And we weren't able to automatically test these scenarios that required a reboot. In other words the Windows installer, that merely just extracted some files in a folder, required, to support the installation of WSL and HyperV, an advanced knowledge of WiX toolkit and of the Windows Installer SDK, plus contributors-time to manually test the scenarios that require a reboot. We decided to remove this capability based on the following reasons: - We had a couple of regressions in the last month that were hard to analyse and fix (containers#24624 and containers#24735) - Podman maintainers currently have a scarce knowledge of the Windows Installer and there is no plan to invest in that - Manually installing WSL or HyperV is not hard (e.g. run `wsl --install`) and are features that admins can manage on their fleet of Windows machines - Competitors such as Docker Desktop don't automatically install these components - Podman `machine init` currently verifies if WSL and HyperV are installed and guide the user to install them when they are not Signed-off-by: Mario Loriedo <[email protected]>
l0rd
force-pushed
the
stop-automatic-wsl-hyperv-installation
branch
from
247d34f to
91e4f69
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: l0rd, Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
The Windows installer was able to automatically enable the Windows features for WSL or HyperV when they were not already enabled. This PR removes this capability.
Having the installer enable the prerequisite (WSL or HyperV) automatically was helpful, as users didn't have to do that themselves. However, it also made the installer's code more complicated, as it needed to manage the installation of these OS features and a reboot. We weren't able to automatically test these scenarios that required a reboot.
In other words, the Windows installer, which merely extracted some files in a folder, required an advanced knowledge of the WiX toolkit and the Windows Installer SDK to support the installation of WSL and HyperV, plus contributors' time to manually test the scenarios that require a reboot.
We decided to remove this capability based on the following reasons:
wsl --install) and are features that admins can manage on their fleet of Windows machinesmachine initcurrently verifies if WSL and HyperV are installed and guides the user to install them when they are notDoes this PR introduce a user-facing change?