Improve libcontainer's systemd cgroup driver #2007
I'm opening this issue to track improvements on systemd cgroup driver I and some others are working on.
The main motivations to improve the systemd cgroup driver are:
The steps I have in mind for this series of refactorings is:
One large concern here is testing. I was talking to @mrunalp about this and he offered to help. Since running this setup on a container can be challenging, he suggested using an external test runner, possibly monitoring GitHub PRs and reporting changes back to GitHub. We'll be working on this testing and will report back here when we have more details. (We might open separate issues to track testing on systemd as well.)
I'm planning to join the OCI call on Wednesday March 13th (also to discuss related opencontainers/runtime-spec#1005 and opencontainers/runtime-spec#1002), so I'm happy to talk more about this libcontainer systemd cgroup driver improvement proposal.
The text was updated successfully, but these errors were encountered:
The testing introduced in #2014, which runs on Travis-CI, which happens to use Ubuntu Xenial, which includes systemd v229 (much older than the one I was testing with) made it clear that it's hard to have libcontainer make a heavier use of systemd properties in StartTransientUnit while maintaining compatibility with older versions of systemd, which is an objective to be preserved.
So I'm changing my approach slightly here. Instead of refactoring the current code, I'll write a new implementation that works in unified cgroup hierarchy only and then use that code only when unified cgroup hierarchy is detected, falling back to the current code in case the hybrid or legacy hierarchy is in use.
The issue with backward compatibility of properties is still a relevant issue, so I opened issue systemd/systemd#12460 requesting a better solution for that. True, that will only be available in systemd v243 or v244, but since no mainstream Linux distributions have switched to using unified hierarchy by default yet and by the time they do they'll probably have a systemd version that includes that code, we should be OK (in any case, the libcontainer code will implicitly check that a systemd version that includes that feature will be running, so while "unified cgroup hierarchy" is the trigger, there are other components that need to be in place for this all to work correctly.)
This also helps answer the question of having all the features supported in the cgroup2 mode (such as cpuset and freezer cgroup), since we will only activate the new implementation once all the components are in place (kernel 5.2 for freezer support in cgroup2, systemd v244 or maybe v245 to include the D-Bus RPCs to expose cpuset and freezer, etc.) Again, using "unified cgroup hierarchy" as the trigger, but knowing there are more dependencies that need to be in place for that to work.
So I'll close #1991 for now, since the final approach will be different. I opened #2047 to push the constructor of the systemd cgroup driver into the systemd module itself, that way when there are two separate implementations of it (one for "legacy" and another for "unified"), that point can serve as detection to make the decision.