Hi @psschwei. 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.

Did anything change with the portforward test? Seems it passed in some runs and failed in others:

E0505 14:03:37.868876   17020 portforward.go:406] an error occurred forwarding 12002 -> 12003: error forwarding port 12003 to pod 43c0bad530f5f826257f7e14f653046147445373508f992900d128902e5773e7, uid : failed to execute portforward in network namespace "host": failed to connect to localhost:12003 inside namespace "43c0bad530f5f826257f7e14f653046147445373508f992900d128902e5773e7", IPv4: dial tcp4 127.0.0.1:12003: connect: connection refused IPv6 dial tcp6 [::1]:12003: connect: connection refused 
E0505 14:03:37.868993   17020 portforward.go:234] lost connection to pod

Did anything change with the portforward test? Seems it passed in some runs and failed in others:

E0505 14:03:37.868876   17020 portforward.go:406] an error occurred forwarding 12002 -> 12003: error forwarding port 12003 to pod 43c0bad530f5f826257f7e14f653046147445373508f992900d128902e5773e7, uid : failed to execute portforward in network namespace "host": failed to connect to localhost:12003 inside namespace "43c0bad530f5f826257f7e14f653046147445373508f992900d128902e5773e7", IPv4: dial tcp4 127.0.0.1:12003: connect: connection refused IPv6 dial tcp6 [::1]:12003: connect: connection refused 
E0505 14:03:37.868993   17020 portforward.go:234] lost connection to pod

https://github.com/kubernetes-sigs/cri-tools/blame/master/pkg/validate/networking.go#L193 but I don't think that change could be the problem.

is possible the host just hasn't exposed the port

https://github.com/containerd/containerd/blob/main/pkg/cri/server/sandbox_portforward_linux.go#L75-L82

/ok-to-test

hmm.. vagrant (rocky /fedora) not picking up the skip for HostIpc is true

https://github.com/containerd/containerd/blame/main/Vagrantfile#L273

ah.. the report dir env variable isn't set so it "ate" the skip

@psschwei rebase when you get a chance to pick up #6900

i'll cherry 6900 after you verify the fix here...

still not skipping ..

ok.. critest --ginkgo.focus="HostIpc" --ginkgo.skip="HostIpc is true" works but add --parallel=2

and it fails to focus or skip

even with ginkgo v2 --parallel=2 just does not work anymore

have to add this: go install github.com/onsi/ginkgo/v2/ginkgo@latest to get critest parallel to work

Just FYI, I compared some runs with the parallel flag working against this PR. While it is a "huge" jump for this specific test in isolation (sample: 2m46s - 2m50s vs. 1m51 - 2m01s), those 40-50 seconds are being added to an overall CI run that averages 25-28 minutes, so I don't think this is a huge problem to not be parallelized until we solve the gingko issue.

Cherry picked in #6895

Just FYI, I compared some runs with the parallel flag working against this PR. While it is a "huge" jump for this specific test in isolation (sample: 2m46s - 2m50s vs. 1m51 - 2m01s), those 40-50 seconds are being added to an overall CI run that averages 25-28 minutes, so I don't think this is a huge problem to not be parallelized until we solve the gingko issue.

nod.. for me running in parallel is more about finding "random" timing issues... we run parallel 8 over in ci.yaml.. and I agree not a big issue.. just don't want to forget about it.. Talked to Sascha will work on it with him next week.