Containerd 2.2: support setting max-concurrent-unpacks

[ytsssun]

Issue number:

Related: #806

Description of changes:

Expose containerd 2.2's max_concurrent_unpacks transfer service setting via settings.container-runtime.max-concurrent-unpacks, and add warning infrastructure for variants using older containerd versions.

Containerd 2.2 templates:

• Added {{#if settings.container-runtime.max-concurrent-unpacks}} block to containerd-config-toml_k8s_containerd_sock and containerd-config-toml_k8s_nvidia_containerd_sock, rendering max_concurrent_unpacks under [plugins."io.containerd.transfer.v1.local"]

Unsupported setting warning (containerd 1.7 and 2.1):

• New unsupported-setting-warning@.service and unsupported-setting-warning@.timer systemd template units in the release package (same pattern as deprecation-warning@)
• Warning template max-concurrent-unpacks-unsupported added to containerd-1.7 and containerd-2.1 packages — writes an env file to /etc/unsupported-settings/ when the setting is configured
• Timer fires on startup and every 6 hours, logging: The setting "container-runtime.max-concurrent-unpacks" is not supported by the containerd version in this variant and has no effect.

Depends on bottlerocket-os/bottlerocket-settings-sdk#119 for the settings model.

Testing done:

Built aws-k8s-1.35 variant with both containerd 2.2 and containerd 2.1, using the setting introduced in bottlerocket-os/bottlerocket-settings-sdk#119. Launched EC2 instances with settings.container-runtime.max-concurrent-unpacks = 5 in user data.

Containerd 2.2:

• /etc/containerd/config.toml renders max_concurrent_unpacks = 5 under [plugins."io.containerd.transfer.v1.local"] ✅
• No warning in journal ✅

Containerd 2.1:

• max_concurrent_unpacks not rendered in containerd config ✅
• Timer active, journal warning: The setting container-runtime.max-concurrent-unpacks is not supported by the containerd version in this variant and has no effect. ✅

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[ytsssun]

Putting to draft as the depending bottlerocket-os/bottlerocket-settings-sdk#119 is not yet merged.

[vigh-m]

I'm wondering if there is a way to piggyback on what already exists for deprecation-warning@ instead of creating new timers and services.
We can potentially put the unsupported-setting@.service in the same path as the deprecation-warning and reuse the time?

[ytsssun]

I'm wondering if there is a way to piggyback on what already exists for deprecation-warning@ instead of creating new timers and services. We can potentially put the unsupported-setting@.service in the same path as the deprecation-warning and reuse the time?

Yeah, the implementation is basically mimicking what we did for deprecation-warning, but you can probably tell that semantically, it has different meaning here - the setting max-concurrent-unpacks is not a deprecated setting, instead it is a new setting that the older containerd versions does not support.

And due to the difference in the semantic of these two, the warning message will be different, in which case a separate service makes sense to me. We can arguably reuse the timer, but unsupported-setting-warning@.timer seems more consistent here?

[vigh-m]

That's fair. The consistency of naming over code reuse is an acceptable tradeoff. :)

[piyush-jena]

The commits are a bit messed up on this one. The settings-sdk bump has schnauzer fixes as well. You may rebase not as my PR with the settings-sdk is merged.

[ytsssun]

The commits are a bit messed up on this one. The settings-sdk bump has schnauzer fixes as well. You may rebase not as my PR with the settings-sdk is merged.

Yes, just dropped the commit in my PR for the settings sdk bump.

[ytsssun]

Force pushed drop the commits to bump settings sdk as that is merged along with #901.

Also addressed comments per @arnaldo2792

[piyush-jena]

nice