go.mod update to containerd v2

[apostasie]

Similar to #2902 - with the difference that it uses personal forks for pending PRs against important dependencies (updated against containerd v2).

Currently:

• fully updated to containerd v2 without any indirect to v1.7
• does build and run
• all dependencies have been updated to containerd v2
• unit test pass
• rootless tests pass
• rootful tests pass - some timeout failures currently
• windows is working

Upsteam dependencies to merge:

• Update dependencies (containerd v2) data-accelerator/zdfs#3
• (blocked, depends on zdfs ^) Update dependencies (containerd v2) accelerated-container-image#290
• Containerd v2.0.0-rc.3 stargz-snapshotter#1722
• (blocked, depends on stargz) TBD nydus
• https://github.com/awslabs/soci-snapshotter/pull/1305/files

Upstream dependencies that do not have a proper PR (only our fork):

• Moby sysinfo package - folder has been copied under here for now - there is a couple of PRs hanging around but they look very stale (Derek' six months+ Update containerd to 2.0 moby/moby#47255 )
• hcsshim: has to be patched against their latest released version, and not main - main is breaking API, which would mean updating containerd against that (and it is probably unstable / untested anyhow). Our fork has a v2-backport branch that does that.
• nydus: current fork is bare minimum and there is definitely some more work needed on their CI tooling needed - it is based off main, which might not be the right choice - finally, nydus depends on stargz and hcsshim, which means these two have to get in first

[apostasie]

@AkihiroSuda

See initial comment up there ^.

That was quite a trek, but CI is finally mostly green - and nothing depends on containerd v1.
I am a bit concerned over the failing ones though, timeouts feel like maybe something is deadlocked somewhere.

Anyhow, obviously this cannot be merged, since it depends on my forks - upstream PRs have to be merged first.
I opened a bunch of them already, and have more to come from my forks.
I can use some help there to move them along - I am not sure why they are blocked - I guess people are busy.

Specifically, moving these two that have been there for a couple of weeks now would get us started:

• Update dependencies (containerd v2) data-accelerator/zdfs#3
• Containerd v2.0.0-rc.3 stargz-snapshotter#1722

Then we can look into the best approach for hcsshim and the rest.

Cheers.

[apostasie]

Will rebase soon now that the stargz PR is in.

[apostasie]

Latest state of affairs:

• see top level comment for dependencies status updated list
• CI is green EXCEPT test-integration-20.04-v1.6.33 which seems to hang on something and timeout - do we care? is 1.6 going to be deprecated with the release of v2?
• next important focus will be hcsshim - see discussion at: Vendor containerd 2.0 microsoft/hcsshim#1958 (comment)

[apostasie]

Status update:

Work is going on for nydus: containerd/nydus-snapshotter#604

Nydus may be the last dep we need (as we may be able to ignore hcsshim for now).

[apostasie]

@AkihiroSuda we are getting closer.

nydus was a lot more work than I thought and I had to send multiple PRs for a variety of issues that are pending.

At this point, we need nydus to come through, and then the soci PR to get in (maybe we can convince them to have it on an ad-hoc branch meanwhile, as they want to wait post-v2-release).

As far as nerdctl CI here is concerned, we get consistently green, with two exceptions:

• TestVolumeLsFilter is failing a lot on Windows #3228 which is racy, and possibly unrelated to containerdv2, and also TestTailFollowRotateLogs is still failing #3225 are still failing a lot
• ubuntu 20.04 + containerd 1.6 seems to always hit the timeout - either it is slower than before, or it is deadlocking for whatever reason

Question for you: when ctd v2 is out, should we still care about that (u 20.04 + containerd 1.6)? I can go and debug this, but only want to spend time on this if we actually care about it :-)

LMK your thoughts.

Thanks.

[AkihiroSuda]

Thank you @apostasie for this hard work!

nydus was a lot more work than I thought and I had to send multiple PRs for a variety of issues that are pending.

If it takes time, we can temporarily remove the support for nydus in nerdctl v2.0 and then put it back in v2.1+.
I think this is acceptable, as we are bumping up the major version.
Same applies to SOCI too.

Question for you: when ctd v2 is out, should we still care about that (u 20.04 + containerd 1.6)?

Yes, as they haven't reached EOL yet.

[apostasie]

@AkihiroSuda

We are there:

1. nydus and soci have been resolved - all dependencies we needed have been migrated and we are now using them instead of my forks
2. the ONE exception to above is moby/pkg/sysinfo - I did fork it out into ./pkg/sysinfo - I do not see another good solution (some discussion with Sebastiaan over here: Update to containerd v2 nydus-snapshotter#604 (comment)) - also see note in go.mod and in pkg/sysinfo/README.md - let me know if this OK
3. CI is green

EXCEPT Ubuntu 20.04 + containerd 1.6 it just hangs-up on inside TestStats and sits there forever - This definitely has to do with nerdctl stats and cgroups version, and I am out of my depth here. I'll keep investigating, but any pointer would be welcome - cc @fahedouch maybe you have an idea? (maybe related to #223) <- nvm, I figured it out. Sorry for the noise

This is ready for a first review.

[apostasie]

Rebased.

[apostasie]

@AkihiroSuda PTAL at your convenience.
No rush of course.
I'll keep rebasing this when it drifts.

[djdongjin]

Personally I don't think we need to separate these dependencies. now dependencies from github.com are split into 2 blocks. And in some places github.com/opencontainers deps are colocated with github.com/containerd deps.

[apostasie]

I can revert this. No strong opinion one way or the other, but I am interested in having one consistent style across (which we do not have now).

[djdongjin]

lgtm, thanks

[apostasie]

lgtm, thanks

Thanks a lot for your time and review @djdongjin
Appreciated.

[apostasie]

@AkihiroSuda: comments addressed.

[AkihiroSuda]

Thanks