Rancher Desktop 1.17.1 - Behaviour differences between 1.17.1 and 1.17.0/1.16.0

[smorton-planview]

I started last week evaluating RD as a drop in replacement for Docker Desktop. For the most part everything has been working great. I did find a scenario late last week that has me puzzled.

I have a container that utilizes MSSQL. I bring my container up and proceed to upgrade the db via our internal upgrade process. I am using dockerd (moby) as the container engine.

This works fine under RD 1.17.0 and 1.16.0. I didn't test any older releases. When I do the same test on the latest release (1.17.1) the upgrade process produces deadlocks within SQL server and never completes.

I have tried the same process with DD versions 4.38.0 and 4.37.2 and cannot reproduce the issue. Besides dependencies I don't really see much change from RD 1.17.1 and 1.17.0 so I am at a loss.

Anyone have an ideas as to why I may be seeing this behavioural difference in versions?

Any help on this would be greatly appreciated.

[jandubois]

Besides dependencies I don't really see much change from RD 1.17.1 and 1.17.0 so I am at a loss.

The major change between 1.17.0 and 1.17.1 is the downgrading of gvisor-tap-vsock from 0.8.1 to 0.7.5 on Windows, and upgrading to 0.8.2 on macOS/Linux.

This should not affect any code running inside a container, with the exception of network related functionality.

Are you using Windows or macOS/Linux? If on macOS, do you use QEMU or VZ. Maybe try switching between them? Do you have any more information on how the server hangs, or a way to reproduce it with publicly available images/tools/data?

[smorton-planview]

The DB upgrade process is a series of steps that execute in order. We are speculating that a step has not 100% completed before the next step is triggered which in turn causes a deadlock. I have tried replacing the Docker engine in the Rancher Desktop WSL VM and I still see the issue. It is an interesting issue to say the least.

[smorton-planview]

I am using Rancher Desktop on Windows. Unfortunately I cannot share the repro, sorry.

[jandubois]

I understand. I just can't think of anything else we can do to help you investigate this further.

[smorton-planview]

I few of the guys I work with are going to try and create a repro scenario. I will update you if we are successful on our end.

[smorton-planview]

The issue we were experiencing in 1.17.1 no longer exists in the 1.18.0 release. I suspect it may have been caused by gviser-tap-vsock but cannot say this 100% confidence.

Thanks