Shuttleworth: Losing graciously

Posted Feb 18, 2014 19:54 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Shuttleworth: Losing graciously by fandingo
Parent article: Shuttleworth: Losing graciously

>Huh? The kernel cgroups are exposed by system calls to a single writer.
Incorrect. Right now cgroups can be manipulated by any number of processes.

I repeat, IT WORKS ALREADY.

Shuttleworth: Losing graciously

Posted Feb 18, 2014 20:44 UTC (Tue) by fandingo (guest, #67019) [Link] (6 responses)

The subject has been thoroughly covered: cgroupsfs as provided by the kernel will eventually go away. There's no ambiguity to the situation. It is being left on for the short-term, so user space is not broken immediately.

You're complaining about a deprecated feature will be removed. You have four options:

1) Start using the systemd or CGManager DBus APIs.

2) Use CGManager with its cgroupfs provider.

3) Implement spitemanager for whatever API (presumably cgroupfs) you desire.

4) Fork the kernel or stop using new versions.

Shuttleworth: Losing graciously

Posted Feb 18, 2014 21:04 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

I should point out that libvirt is also planning on providing transitional cgroupfs support for hosts not using systemd as manager yet, for libvirt based container users. That's not to say that libvirt provides universal use case coverage. Just pointing out that libvirt was yet another cgroupfs writer and that it has a transition plan in place to work in the single writer world right now and the transition plan is documented on the libvirt project site. They have no plans for cgmanager support yet, but as the api for cgmanager hasn't really been communicated as stable yet, can't really expect them to be able to support that api.

Though it is interesting to see if Ubuntu patches libvirt as shipped in Trusty to talk to cgmanager. Right now it it appears that libvirt as packaged in Trusty isn't patched for that yet and will be relying on the cgroupfs in 14.04. So that's an interesting little wrinkle. Will a trusty host running cgmanager be able to work with trusty libvirt based containers?

Shuttleworth: Losing graciously

Posted Feb 18, 2014 21:34 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Basically, all the solutions are sub-optimal compared to the only real solution: use filesystem-based interface.

Shuttleworth: Losing graciously

Posted Feb 18, 2014 21:57 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (3 responses)

What about another system call where a process in a new PID namespace asks to be the manager, the kernel sees that it's in a namespace and asks the parent cgroup manager whether it should be allowed. If it is, the kernel allows delegation of that subtree to only that manager (the parent can't touch inside of it anymore). If the parent denies access, the kernel gives an error to the container manager that the subtree is already managed (I assume there is such an error condition already). Would that be sufficient for the New World Order[1]?

[1]Assuming that you don't somehow convince kernel developers to forego the single-writer changes (which seems very unlikely at this point).

Shuttleworth: Losing graciously

Posted Feb 18, 2014 22:20 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Yes, I have something like this in mind:

0) Regular permissions apply.

1) Add 'pid-lock' file at each level of cgroups tree. Everyone can modify cgroups tree if this file is empty.

2) Once you write a pid into this file only this process can make modifications to this tree level and deeper.

3) The pid-lock process can modify pid-lock files in its subtree, either clearing them completely or by writing another pid. It doesn't lose access as long as it's still alive.

4) Subtree moves must respect pid-locks and permissions.

That's basically it. It still allows to lock the tree against accidental modifications and also gives a clear path for delegation. DBUS connoisseurs can still use fully DBUS-based delegation and access control and everybody else can use normal filesystem-based API.

It's also possible to add a bitmask of delegated controllers. For example, so that the parent controller can limit the delegated controllers to cpu manager but not costly memcg.

Shuttleworth: Losing graciously

Posted Feb 19, 2014 14:24 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

Well, fair enough. Are you going to implement it? I think it's hardly a secret that kernel developers are usually not interested in designs that aren't accompanied by working code.

Shuttleworth: Losing graciously

Posted Feb 19, 2014 14:28 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

It'd be worth it to ask whether it would even be considered first at least.