gvisor update / go 1.20 switch

[cfergeau]

Current codebase is buildable with go 1.19 and 1.20, which are the 2 supported releases of go.
If we want to update gvisor ( #219 ), 1.20 becomes required.
I prefer to keep the master branch as it currently is, unless there are critical bug fixes/... required.

We can revisit this in August/September when 1.21 is released(?) and 1.19 no longer supported.

[Luap99]

Looks like the current code does not compile on go 1.21 (now in rawhide) causing failures for the podman rpm builds.
However 1.19 is also still supported in fedora 37, so it seems like we cannot support all three versions with one gvproxy version.
Do we need to patch the gvisor update into the fedora rpm?
Example problem seen in Podman CI: https://dashboard.packit.dev/results/copr-builds/889641
cc @lsm5

[cfergeau]

Looks like the current code does not compile on go 1.21 (now in rawhide)

1.21 is not even released yet, it's a rc version which is in rawhide :-/

However 1.19 is also still supported in fedora 37, so it seems like we cannot support all three versions with one gvproxy version.

Yup, I don't think we'll be able to have a gvisor-tap-vsock version which builds on 1.19, 1.20 and 1.21. Maybe f37 can stay with an older version of the gvisor-tap-vsock codebase while still updating the podman packages as needed?

Do we need to patch the gvisor update into the fedora rpm?

That's an option, but the rawhide package would be significantly different from upstream :-/ Split gvisor-tap-vsock and podman packages as was discussed before would help in this kind of situations, but this hasn't been done yet.

Not sure I'll have time to look closer at this before next week.

[Luap99]

Maybe f37 can stay with an older version of the gvisor-tap-vsock codebase while still updating the podman packages as needed?

That sounds like a good idea to me.

[gbraad]

@Luap99

Not sure I'll have time to look closer at this before next week.

hope this is not a concern, or are you aiming for a release?

[Luap99]

I think we are planning for a podman 4.6.0 today. But I guess if gvproxy cannot build in rawhide it is not the end of the world. In our CI we can just ignore the failure for now.

[lsm5]

broken gvproxy on rawhide would mean broken upgrade path from fedora release to rawhide. We can live with that but should be resolved asap. And as @cfergeau mentioned, separating gvisor-tap-vsock into a standalone package would be best.

[lsm5]

I'm working on a separate gvisor-tap-vsock package now.

[lsm5]

filed a review request at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2224434

also created a PR to remove gvproxy from podman containers/podman#19301 . This will likely stay in draft until the Fedora package is sure to be approved.

[lsm5]

filed a review request at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2224434

@cfergeau @gbraad The package review bz isn't going to go further until gvisor-tap-vsock can build on rawhide. Can we please bump the priority for go1.21 support?

[cfergeau]

filed a review request at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2224434

@cfergeau @gbraad The package review bz isn't going to go further until gvisor-tap-vsock can build on rawhide. Can we please bump the priority for go1.21 support?

See #249