Downgrade gvisor tap vsock #8102
Conversation
This reverts commit f5a1e3a.
This reverts commit 053477d.
Not manually downgrading lima was causing the gvisor-tap-vsock to revert back to the latest version 0.8.1. Also, the gvisor-tap-vsock was reverted back to version 0.7.5 for Networking and guestAgent project. As part of the 1.17.0 release, we upgraded the gvisor-tap-vsock library to version v0.8.1. However, this version has caused issues with DNS resolution behind VPNs and other name resolution problems. To address these issues, we are planning to release a patch, and this downgrade is part of that solution. Signed-off-by: Nino Kodabande <[email protected]>
Nino-K
force-pushed
the
downgrade-gvisor-tap-vsock
branch
from
4003298 to
efcfdd5
Compare
There was a problem hiding this comment.
There should be changes to dependabot.yml to prevent dependabot from trying to bump gvisor-tap-vsock for us. (And to document that we're forcing it to 0.7.5.)
| gvisor.dev/gvisor v0.0.0-20231023213702-2691a8f9b1cf | ||
| ) | ||
|
|
||
| require ( |
There was a problem hiding this comment.
Huh, why is there two sections for indirect requires now?
| github.com/containernetworking/plugins v1.6.2 | ||
| github.com/containers/gvisor-tap-vsock v0.8.1 | ||
| github.com/docker/docker v27.5.0+incompatible | ||
| github.com/containerd/containerd v1.7.24 |
There was a problem hiding this comment.
Not sure we need to downgrade containerd, docker, etc., but hopefully this fixes the issues and then we can think about it later.
There was a problem hiding this comment.
Yes, this seems wrong. We should not downgrade any other direct dependencies, except for gvisor-tap-vsock. We may downgrade indirect dependencies, whatever go mod tidy decides, but the direct dependencies must stay as-is.
Dependabot will bump them back up right away anyways!
Should we update the dependabot? or should we decide not to accept the PRs that dependabot creates? |
| github.com/containernetworking/plugins v1.6.2 | ||
| github.com/containers/gvisor-tap-vsock v0.8.1 | ||
| github.com/docker/docker v27.5.0+incompatible | ||
| github.com/containerd/containerd v1.7.24 |
There was a problem hiding this comment.
Yes, this seems wrong. We should not downgrade any other direct dependencies, except for gvisor-tap-vsock. We may downgrade indirect dependencies, whatever go mod tidy decides, but the direct dependencies must stay as-is.
Dependabot will bump them back up right away anyways!
I believe that was done as part of running |
I'm fine with just turning the specific PR from dependabot for |
This should be temporary until we can find a newer version that resolves the DNS issues. Signed-off-by: Nino Kodabande <[email protected]>
| // The inet.af domain was lost: https://github.com/inetaf/tcpproxy/issues/39 | ||
| // We can't just `require` github.com/inetaf/tcpproxy, as gvisor-tap-vsock | ||
| // still imports inet.af/tcpproxy: https://github.com/containers/gvisor-tap-vsock/pull/399 | ||
| replace inet.af/tcpproxy => github.com/inetaf/tcpproxy v0.0.0-20240214030015-3ce58045626c |
There was a problem hiding this comment.
Note that this is a different version compared to what we actually require. Is that expected? I'd have thought we'd use the same commit (because the replacement repo has the full history).
As part of the 1.17.0 release, we upgraded the gvisor-tap-vsock library to version v0.8.1. However, this version has caused issues with DNS resolution behind VPNs and other name resolution problems. We plan to release a patch to address these issues, and this downgrade is part of that solution.
Related to: #8055