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

I'm not too sure about the value of backporting since this is technically a breaking change.

I'm hesitant about this too, especially with 1.6 moving to a long term stable status.

/ok-to-test

I think it's okay to not backport this change. The KubeVirt feature will be behind a feature gate. For vendors who want to use the feature, they can backport this change to their own containerd build.

Results of discussion in community meeting: this one is OK for 1.7 but too risky for 1.6. If needed for 1.6 it can be manually backported by users or we can add a hardcoded workaround for Kubevirt via runtime handlers.

I think it's okay to not backport this change. The KubeVirt feature will be behind a feature gate. For vendors who want to use the feature, they can backport this change to their own containerd build.

I wish Docker had done the same, instead they backported this into a patch release breaking customera systems without notice.

Even worst, the only way we found to enable these was to do an emergency deployment of a seccomp profile.