Hi @Iceber. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 8m 13s (non-voting)

Let's please wait for a release of k8s (1.21) before we merge this change in. (at least a release candidate)

@dims I feel like we should have a written plan somewhere about the ideal flow of pause updates, previously we qualified these at the very least with dockershim xref: kubernetes/kubernetes#98205 (comment)

It's not clear to me why this needs to wait for a k8s release though, it should be independent?
The image is already publicly available to consumers and won't be mutated, so 3.4.1 will be fine as long as it works here.

What's the concern with updating before a k8s release?

Presumably any CI here creating pods tests this change?

@BenTheElder i'd like to get the kubernetes/kubernetes#98205 merged first.

then i'd like to watch periodics for a bit - example : https://testgrid.k8s.io/sig-node-release-blocking#node-kubelet-master

[dims@dims-a01 22:10] ~/Downloads ⟩ rg 'container-runtime="docker"'
tmp-node-e2e-f61ec3da-cos-81-12871-1245-6/kubelet.log
38:Feb 07 01:28:33 tmp-node-e2e-f61ec3da-cos-81-12871-1245-6 kubelet[1861]: I0207 01:28:33.020269    1861 flags.go:59] FLAG: --container-runtime="docker"

tmp-node-e2e-f61ec3da-ubuntu-gke-1804-1-16-v20200330/kubelet.log
37:Feb 07 01:28:35 tmp-node-e2e-f61ec3da-ubuntu-gke-1804-1-16-v20200330 kubelet[3752]: I0207 01:28:35.342940    3752 flags.go:59] FLAG: --container-runtime="docker"

tmp-node-e2e-f61ec3da-cos-85-13310-1209-7/kubelet.log
38:Feb 07 01:28:33 tmp-node-e2e-f61ec3da-cos-85-13310-1209-7 kubelet[1975]: I0207 01:28:33.349476    1975 flags.go:59] FLAG: --container-runtime="docker"

to confirm things are fine, before we make the change here in containerd.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 6m 48s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 7m 00s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 7m 28s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 6m 01s (non-voting)

@dims how long do we want to monitor upstream? It's been a few weeks now.

/ok-to-test

@BenTheElder we resurrected the pull-containerd-node-e2e job a couple of days ago. kicking that off. once it goes green, let's go ahead with this.

LGTM

Build succeeded.

• containerd-build-arm64 : SUCCESS in 5m 42s (non-voting)

@mikebrow @dims @BenTheElder rebased and it's green.

still tracking some issues with the node e2e tests both here and in k/k. Looks like the test suite passed here but the job is not marked pass/fail. so let's just treat this as 🟢 and move forward.

As long as the windows is a flake, so we may have to rerun it.

I'm prepared to roll forward with this in kind, I don't expect any issues with this image.