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

The only thing I was wondering here is: main branch is for containerd v2, and IIRC there would be some breaking changes in the config; from that perspective, do we need the backward compatibility (not sure what the scope of breaking changes is in the config; is it only deprecating fields or also other breaking changes?)

Hi @thaJeztah

The only thing I was wondering here is: main branch is for containerd v2, and IIRC there would be some breaking changes in the config;

I think we can consider to keep this backward compatibility because we can use 5s to setup the value instead of 5000000000. It's easy to setup the value. What do you think?

The extra work required to maintain this compat seems quite small. So i guess it's better to keep the current user experience?

Yes, sounds good to me; I wasn't 100% sure of the impact, so wanted to be sure we were not taking on maintenance for things that would already have (partially) breaking changes; so thought I'd at least mention 👍

/retest

@lengrongfu: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.