CGroups manager API [LWN.net]

CGroups manager API

Posted Dec 5, 2013 23:02 UTC (Thu) by drag (guest, #31333)
In reply to: CGroups manager API by rvfh
Parent article: Another daemon for managing control groups

> On a slightly different note, what is your take on trying to have the same API as cgroupsmanager

It seems that systemd and cgroupsmanager have distinctly different goals in managing cgroups.

Systemd is looking to provide a high level API that piggy backs on the process management features that already exist and are being used by systemd.

It appears from the posts that I read that cgroupsmanager is looking to expose most of the the functionality of cgroupfs via dbus because the kernel developers are going to depreciate the current cgroupfs API and are discouraging having multiple processes from being able to manage hierarchical cgroups in the future.

It's the difference between trying to make something secure and easy to manage versus something that wants to allow as much flexibility as possible.

to post comments

CGroups manager API

Posted Dec 6, 2013 1:46 UTC (Fri) by raven667 (guest, #5198) [Link]

I think thats a good summary, the question is whether there is value in systemd also offering the low level interface like cgroupsmanager intends, in addition to the high level interface, or would that break systemd service management if it exposed all the low level details? What kind of clients are expected to be using either of these interfaces, is this for virtualization management agents to setup containers across a shared cluster for customer jobs? Can this use case be accomplished with the kind of interface that systemd is planning to export or does it require the more low level interface that cgroupsmanager intends to export, or can the intended use cases for the dbus interface be accomplished with either system?

It would probably be suboptimal if an application need would create hard dependancies up the stack all the way to the init system such that certain workloads fundamentally can't be run on systems with incompatible init systems. I would prefer to pick the best init system (which I think is systemd) and not lose the ability to run whatever services I want.