Container Runtime can not be switched

[spencer-cdw]

Actual Behavior

As a user, when I open RancherDesktop Preferences at attempt to change the runtime from 'containerd' to 'docker (moby)', the 'apply' button does not apply changes. Attempting to exit the window will clear out any images.

Steps to Reproduce

Install Rancher on windows open preferences attempt to change container runtime

Result

You will observe that the 'apply' button does not apply the changes. Attempting to exit the gui will undo the changes

Expected Behavior

Apply button should work correctly

Additional Information

No response

Rancher Desktop Version

1.5.1

Rancher Desktop K8s Version

NA

Which container engine are you using?

containerd (nerdctl)

What operating system are you using?

Windows

Operating System / Build Version

Windows 10 Enterprise

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

VPN N/A No additional software

This used to work in older versions of rancher. Have tried uninstalling and reinstalling rancher with no luck Have tried running as administrator Have tried multiple reboots

[spencer-cdw]

I downgraded to 1.4.1 and I am able to switch container runtime succesfully

[rak-phillip]

@spencer-cdw thanks for raising this issue and helping to make Rancher Desktop better!

I suspect that the behavior you are seeing might be related to #2675. Can you post the contents of background.log for 1.5.1 to see if we can capture the mainEvents settings-update event?

[adamkpickering]

Also, please enable debug mode in the Troubleshooting tab before reproducing the issue and posting the contents of the log. That will ensure that the logs contain the most info.

[spencer-cdw]

This does appear to be a duplicate of #2675.

I have found a work around to change the container runtime. But I find that on 1.5.1 I'm not able to revert back to 'containerd'. I see the same result where the apply button does nothing.

I have enabled debugging in the logging, and restarted rancher-desktop.

Here is the output of the logs. They seem suspiciously not very verbose

background.log

2022-08-24T19:30:50.783Z: Stopping background process Win32 socket proxy.
2022-08-24T19:30:50.789Z: mainEvents settings-update: {"version":4,"kubernetes":{"version":"","memoryInGB":2,"numberCPUs":2,"port":6443,"containerEngine":"moby","checkForExistingKimBuilder":false,"enabled":false,"WSLIntegrations":{},"options":{"traefik":true,"flannel":true},"suppressSudo":false,"experimentalHostResolver":false,"hostResolver":true},"portForwarding":{"includeKubernetesServices":false},"images":{"showAll":true,"namespace":"buildkit"},"telemetry":true,"updater":false,"debug":true,"pathManagementStrategy":"notset"}
2022-08-24T19:30:50.964Z: Stopping background process Win32 socket proxy.
                                                                                                                                                                                                                                                                                                                                                                                             2022-08-24T19:30:47.559Z: Stopping background process host-resolver vsock host.
2022-08-24T19:30:53.022Z: Background process Vtunnel Host Process exited with status 1 signal null
2022-08-24T19:30:53.022Z: Background process Vtunnel Host Process will restart.
2022-08-24T19:30:54.022Z: Launching background process Vtunnel Host Process.
2022-08-24T19:31:04.381Z: Background process Vtunnel Host Process exited with status 1 signal null
2022-08-24T19:31:04.382Z: Background process Vtunnel Host Process will restart.
2022-08-24T19:31:05.393Z: Launching background process Vtunnel Host Process.
2022-08-24T19:31:12.904Z: Background process Win32 socket proxy exited with status 1 signal null
2022-08-24T19:31:12.905Z: Background process Win32 socket proxy will restart.
2022-08-24T19:31:13.668Z: Launching background process host-resolver vsock host.
2022-08-24T19:31:13.910Z: Launching background process Win32 socket proxy.
2022-08-24T19:31:16.228Z: Background process Vtunnel Host Process exited with status 1 signal null
2022-08-24T19:31:16.228Z: Background process Vtunnel Host Process will restart.
2022-08-24T19:31:17.232Z: Launching background process Vtunnel Host Process.
2022-08-24T19:31:20.712Z: mainEvents settings-update: {"version":4,"kubernetes":{"version":"","memoryInGB":2,"numberCPUs":2,"port":6443,"containerEngine":"moby","checkForExistingKimBuilder":false,"enabled":false,"WSLIntegrations":{},"options":{"traefik":true,"flannel":true},"suppressSudo":false,"experimentalHostResolver":false,"hostResolver":true},"portForwarding":{"includeKubernetesServices":false},"images":{"showAll":true,"namespace":"buildkit"},"telemetry":true,"updater":false,"debug":true,"pathManagementStrategy":"notset"}
2022-08-24T19:31:20.726Z: Launching background process Win32 socket proxy.
2022-08-24T19:31:20.763Z: Launching background process Win32 socket proxy.
2022-08-24T19:31:20.884Z: Background process Win32 socket proxy exited gracefully.
2022-08-24T19:31:20.884Z: Not current Win32 socket proxy process; nothing to be done.
2022-08-24T19:31:24.112Z: Background process host-resolver vsock host exited with status 1 signal null
2022-08-24T19:31:24.112Z: Background process host-resolver vsock host will restart.
2022-08-24T19:31:25.119Z: Launching background process host-resolver vsock host.

[spencer-cdw]

While issue #2675 is closed, it only partially fixes the issue.

Users still will get an error if kubernetes version is not defined. The user needs to enable kubernetes, select the version, then disable kubernetes in order to be able to change the container runtime.

Solution

1. Rancher desktop should define a kubernetes version by default

or

2. Rancher desktop should allow users to change container runtimes without specifying kubernetes version

Additional information on workaround documented here: https://github.com/rancher-sandbox/rancher-desktop/issues/2675#issuecomment-1226162371

[rak-phillip]

I'm thinking option 2 might make more sense in this scenario. It sounds like we don't care about a version when Kubernetes is disabled and we'd be able to disable the check if this is the case

https://github.com/rancher-sandbox/rancher-desktop/blob/bf95894e950587d224054216c5c8b5642bd2037f/src/main/commandServer/settingsValidator.ts#L230-L238

@mook-as what do you think?

[mook-as]

Yeah, skipping the kube version check (when it's unused) seems reasonable. Alternatively, we could just flip the check around and skip the whole thing if it's unmodified (move line 237 up).