feat: support containerd 2.x addon#6029
Conversation
|
Testgrid Run(s) Executing @ https://testgrid.kurl.sh/run/pr-6029-f433091-containerd-2.2.0-k8s-ctrd-2026-06-12T06:22:25Z |
|
Testgrid Run(s) Executing @ https://testgrid.kurl.sh/run/pr-6029-f433091-containerd-2.2.2-k8s-ctrd-2026-06-12T06:22:52Z |
|
Testgrid Run(s) Executing @ https://testgrid.kurl.sh/run/pr-6029-f433091-containerd-2.2.1-k8s-ctrd-2026-06-12T06:23:07Z |
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| function test_migration_steps_1_7_to_2x() { | ||
| CONTAINERD_STEP_VERSIONS=(1.2.13 1.3.9 1.4.13 1.5.11 1.6.33 1.7.29 2.0.5) | ||
| local steps | ||
| steps="$(containerd_migration_steps "1.7.29" "2.0.5")" | ||
| assertEquals "migration steps 1.7->2.0" "2.0.5" "$steps" | ||
| } |
There was a problem hiding this comment.
test_migration_steps_1_7_to_2x uses STEP_VERSIONS that includes 2.0.5, but the actual scripts/Manifest has no 2.0.x entry — only 2.1.5 and 2.2.4. When a 1.7 → 2.1 or 1.7 → 2.2 migration is evaluated with the real step set, the while loop in containerd_migration_steps fires with current_minor=8 > install_minor, so the loop is skipped and only $to_version is returned — which is the correct result. However there are no tests asserting this exact path. Adding a test case for "1.7.29" → "2.1.5" and "1.7.29" → "2.2.4" with the production STEP_VERSIONS would guard against future regressions.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| if [ "${config_schema_version:-2}" -ge "3" ]; then | ||
| # Validate the effective merged config: the dump must parse cleanly AND contain the | ||
| # drop-in's settings, proving the conf.d import survived any CONTAINERD_TOML_CONFIG patch. | ||
| if ! containerd --config /etc/containerd/config.toml config dump | grep -q 'SystemdCgroup = true'; then | ||
| bail "containerd drop-in /etc/containerd/conf.d/99-replicated.toml was not applied to the merged config" | ||
| fi |
There was a problem hiding this comment.
SystemdCgroup
The post-configure validation checks that SystemdCgroup = true survived the drop-in merge, which proves the imports patch and drop-in write succeeded. However it doesn't validate the pause/sandbox image or config_path settings. If the user's CONTAINERD_TOML_CONFIG patch removes the [plugins.'io.containerd.cri.v1.images'.pinned_images] section (or the certs.d path), the installation would silently proceed with the wrong sandbox image or broken registry config. Expanding the grep to also check for config_path (which is always written) would catch a broader class of broken patches with no additional overhead.
|
Testgrid Run(s) Executing @ https://testgrid.kurl.sh/run/pr-6029-f433091-containerd-2.2.3-k8s-ctrd-2026-06-12T06:23:40Z |
|
Testgrid Run(s) Executing @ https://testgrid.kurl.sh/run/pr-6029-f433091-containerd-2.2.4-k8s-ctrd-2026-06-12T06:24:06Z |
|
Testgrid Run(s) Executing @ https://testgrid.kurl.sh/run/pr-6029-f433091-containerd-2.1.5-k8s-ctrd-2026-06-12T06:30:42Z |
1 participant
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Steps to reproduce
Does this PR introduce a user-facing change?
Does this PR require documentation?