buildsys, systemd: add unified-cgroup-hierarchy image feature

[markusboehme]

Issue number:

#2843

Description of changes:

Add a new image feature toggle unified-cgroup-hierarchy. The image feature allows variants to select either cgroup v1 or cgroup v2 (the "unified cgroup hierarchy") as the default for systemd to set up during host boot.

The image feature changes how systemd is configured at build time. This results in slightly differing builds of systemd depending on variants' selected image features. Users can still override the default choice via a command line argument (systemd.unified_cgroup_hierarchy=[01]) supplied via the user data and boot config mechanisms.

Alternatively, the default cgroup version to use could be selected by baking a command line argument into the image. However, this would present a liability since GRUB and its configuration are not being updated during image updates, and some hosts would be stuck with it forever. Whether a user could override this setting via their own command line arguments would come down to parsing logic handles duplicate settings and seems brittle, especially when trying to provide guarantees "forever".

Testing done:

• Modified variants/metal-dev/Cargo.toml to carry unified-cgroup-hierarchy = true in the package.metadata.build-variant.image-features] section
• Built the metal-dev variant
• Confirmed the image booted with a cgroup v2 hierarchy by checking mount | grep cgroup output and only finding a single cgroup2 mount
• Rebuilt the metal-dev variant to confirm the systemd build is cached if the image feature flag doesn't change
• Built the (unchanged) aws-dev variant to confirm systemd and dependent packages get rebuilt if the image feature flag changes

Reviewer notes:

This does not yet make any variant actually default to cgroup v2, but only provides the means to do so. This is still pending version 0.10.0 of the admin container getting deployed, which carries changes to make it work on cgroup v2 hosts.

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.

[bcressey]

However, this would present a liability since GRUB and its configuration are not being updated during image updates, and some hosts would be stuck with it forever.

Pedantic note: it's only the minimal config baked into GRUB that isn't updated, since GRUB itself is never updated. The main GRUB config on the /boot partition does get updated; otherwise the dm-verity hash for the new root filesystem would be incorrect.

Whether a user could override this setting via their own command line arguments would come down to parsing logic handles duplicate settings and seems brittle, especially when trying to provide guarantees "forever".

I previously believed, incorrectly, that boot config could override some of the stock parameters, but you're right that it almost always doesn't work that way, and it's probably best that it doesn't. So while I was surprised to see an image feature flag used here, I agree that it's the correct way to handle it to ensure that nodes can be downgraded into cgroup v1 if needed.

[markusboehme]

However, this would present a liability since GRUB and its configuration are not being updated during image updates, and some hosts would be stuck with it forever.

Pedantic note: it's only the minimal config baked into GRUB that isn't updated, since GRUB itself is never updated. The main GRUB config on the /boot partition does get updated; otherwise the dm-verity hash for the new root filesystem would be incorrect.

Thanks for pointing this out! It indeed is the quite obvious counterexample. I updated the commit message accordingly.