Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 5, 2013 21:42 UTC (Thu) by jubal (subscriber, #67202)
In reply to: Another daemon for managing control groups by jspaleta
Parent article: Another daemon for managing control groups

Are you trying to say that Tim Hockin does not have any idea what cgroups are and how they should be managed, Jef?

(BTW, Lennart, nice hissy fit both here and on your g+ account, additional ten points for class.)

to post comments

Another daemon for managing control groups

Posted Dec 5, 2013 22:35 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (2 responses)

No I'm saying he may not fully understand why the cgroup interface is being reworked because Google's internal use case don't need to consider the security issues Tejun is looking to solve by very deliberately cutting out functionality Tim is currently relying on.

The workman-devel list archived communication in June and July between Tejun and Tim really captures the meat of the dispute. Tim was blindsided by the speed at which systemd's implementation of a manager matured to meet the kernel side development of the new interface. And even though Tejun tries to explain why the kernel interface changes are happening, I never get the feeling Tim understands what Tejun is attempting to communicate. Tim's unhappy that the single heiarchy change is going to land on the kernel side. Tim is unhappy that the new kernel interface is taking away flexibility his use case currently relies on. The kernel side change is coming, regardless of systemd's high level implementation decision on how to deal with that inbound kernel change. It's coming. Tim admits Google already has an in-production in-house developed high level API for cgroup management in some form (oh the irony of that!)

The fact that systemd has a mature implementation of a cgroup manager API for the new kernel interface with kernel dev side buy-in is germane to Tim's core concern only because the maturity of that implementation means he potentially has less time to ignore the new kernel interface and to deal with adapting Google's in-house uncollaboratively developed tooling, by spinning up an alternative implementation to meet the requirements of the new cgroups interface. Even though Tejun diffuses this concern to some degree by stating the older, less secure interface will still be there, and Google should be able to continue running as is.

Thought out the entire discussion Tim's concern is still primarily about the collapse of the multi-hierarchy which Google's use case depends on and the requirement of having a central manager. Tim really doesn't care what systemd is doing as a high level API to wrap the kernel interface. Google isn't going to use it. Google is happy with their in-house tools.

There is a lot to chew on in that workman-devel thread... just in the discussion between Tejun and Tim and ignoring all other discussion. I'm left seriously wondering if Tim really understands and appreciates the security issues Tejun is attempting to solve with the new cgroups interface.

Tejun is serious about cleaning up the cgroup interface. Seriously serious.
The more people start pushing back about the proposed kernel side adjustments with details of how it breaks their use case, the more Tejun's concerns make sense to me from a security persepctive. People are doing some crazy crazy things with cgroups.

Another daemon for managing control groups

Posted Dec 5, 2013 22:53 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

I tried to read the thread and it seems like Tim never explained exactly why they can't do what they want with a single hierarchical structure and Tejun never explained in a understandable way the exact reasons why they cannot maintain a multi-hierarchical interface.

Although you are right that systemd has absolutely nothing to do with it. They'd have the same problem regardless of what method they use to manage cgroups.

Another daemon for managing control groups

Posted Dec 5, 2013 23:23 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

Indeed,

I actually think it was surprising at how quickly systemd spun up a working manager interface. Tejun started this particular ball rolling in Feb/March 2012. LWN covered it. I think a lot of people, who should have been aware of Tejun's plans, just assumed it would take more time for anyone to spin up a working manager implementation for the saner cgroups interface he's spinning up.

The fact systemd that did it this quickly, I think speaks volumes.

The fact that everyone else sat on their hands for a year+ after Tejun's decision also speaks volumes.

Tejun is serious about cleaning up the lawless wild west. I'm not sure enough people took him seriously until systemd landed its public implementation. But really, a year later after Tejun stated his firm intention to move forward and you want to finally start to engage and push back? Meh.

-jef

Another daemon for managing control groups

Posted Dec 6, 2013 1:03 UTC (Fri) by ovitters (guest, #27950) [Link] (2 responses)

(BTW, Lennart, nice hissy fit both here and on your g+ account, additional ten points for class.)

If you don't like someone responding in a certain way, don't be an ass yourself ("nice hissy fit, additional ten points for class").

Another daemon for managing control groups

Posted Dec 6, 2013 14:21 UTC (Fri) by jubal (subscriber, #67202) [Link] (1 responses)

There's a difference between sarcasm and hissy fits.

Another daemon for managing control groups

Posted Dec 10, 2013 9:03 UTC (Tue) by mp (subscriber, #5615) [Link]

Pretty insignificant compared to the similarity in what they do to advance the discussion.