[lxc-devel] LXC 1.0 and feature support on kernel level

[Serge Hallyn]

Quoting Jäkel, Guido (G.Jaekel at dnb.de):
> Dear Core-Developers,
> 
> i would like to ask for a discussion about the status of a kind of improvements that -- as I know -- will need support by the kernel developers. But a LXC (newbie) user may expect such things from a software level 1.0, will miss it. In the worst case, this may have impacts on the image of LXC because one may think it's in the direct concern of LXC to provide it.
> 
> As an example, the cgroups framework offers the (functional) resource limiters for memory and CPU. But for a process within such a group -- here: a container -- there's no adequate projection on the common used interfaces by all the software around: It will determine the memory resources or total number of CPUs of the host. Therefore the user have manually adjust it - if he knows about the fact and the software offer the possibility to override it.
> 
> Is there any ongoing work on this by kernel developers? May there be notable improvements within the timeline of the LXC 1.0 release?

No ongoing work right now or on the 1.0 roadmap iirc.  The previously
considered possible options, in decreasing order of likelyhood to be
acceptable, are:

1. Implement a new library which provides memory and cpu usage, etc.
Move userspace to using those instead of procfiles.

2. Implement a procfs to provide virtualized views of memory and
cpu usage, etc, and integrate it nicely with lxc.  Daniel had
started this years ago, but the last codedrop which I found of
this is pretty badly out of date, so easiest would be to start
from scratch.  Note noone in kernel-land or other packages would
need to get involved.  So in a sense this is more likely than (1)
to be acceptable - but it's not as desirable.  The reason is that
as procfiles and cgroup behavior change, instead of one library
needing updates, every project's own procfs will need to be
maintained.

It might therefore be worthwhile to have a few interested people
work together on an independent such project.  (note that libvirt
has a procfs which is virtualizing exactly one procfile)  In that
sense this would just be (1) moved down a level.

3. Implement filtering of procfiles right in the kernel's procfs
code.  In the past that has been rejected, but then preferred
kernel aesthetics do change (somewhat in cycles) so it's always
possible that, if you do it right, you could succeed.

-serge