Re: 2009 kernel summit preparation for 'containers end-game' discussion

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

"Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Oren Laadan (orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org):
>> Hi,
>> 
>> Serge E. Hallyn wrote:
>> > Hi,
>> > 
>> > the kernel summit is rapidly approaching. One of the agenda
>> > items is 'the containers end-game and how do we get there.'
>> > As of now I don't yet know who will be there to represent the
>> > containers community in that discussion.  I hope there is
>> > someone planning on that?  In the hopes that there is, here is
>> > a summary of the info I gathered in June, in case that is
>> > helpful.  If it doesn't look like anyone will be attending
>> > ksummit representing containers, then I'll send the final
>> > version of this info to the ksummit mailing list so that someone
>> > can stand in.
>> > 
>> > 1. There will be an IO controller minisummit before KS.  I
>> > trust someone (Balbir?) will be sending meeting notes to
>> > the cgroup list, so that highlights can be mentioned at KS?
>> > 
>> > 2. There was a checkpoint/restart BOF plus talk at plumber's.
>> > Notes on the BOF are here:
>> > https://lists.linux-foundation.org/pipermail/containers/2009-September/020915.html
>> 
>> Based on Suka's post, I updated the linux-cr wiki page with the
>> notes from the BOF here:
>> 
>> 	http://ckpt.wiki.kernel.org/index.php/LPC2009
>
> Thanks.
>
>> > 3. There was an OOM notification talk or BOF at plumber's.
>> > Dave or Balbir, are there any notes about that meeting?
>> > 
>> > 4. The actual title of the KS discussion is 'containers end-game'.
>> > The containers-specific info I gathered in June was mainly about
>> > additional resources which we might containerize.  I expect that
>> > will be useful in helping the KS community decide how far down
>> > the containerization path they are willing to go - i.e. whether
>> > we want to call what we have good enough and say you must use kvm
>> > for anything more, whether we want to be able to provide all the
>> > features of a full VM with containers, or something in between,
>> > say targetting specific uses (perhaps only expand on cooperative
>> > resource management containers).  With that in mind, here are
>> > some items that were mentioned in June as candidates for
>> > more containerization work
>> > 
>> > 	1. Cpu hard limits, memory soft limits (Balbir)
>> > 	2. Large pages, mlock, shared page accounting (Balbir)
>> > 	3. Oom notification (Balbir - was anything decided on this
>> > 		at plumber's?)
>> > 	4. There is agreement on getting rid of the ns cgroup,
>> > 		provided that:
>> > 		a. user namespaces can provide container confinement
>> > 		guarantees
>> > 		b. a compatibility flag is created to clone parent
>> > 		cgroup when creating a new cgroup (Paul and Daniel)
>> > 	5. Poweroff/reboot handling in containers (Daniel)
>> > 	6. Full user namespaces to segragate uids in different
>> > 		containers and confine root users in containers, i.e.
>> > 		with respect to file systems like cgroupfs.
>> > 	7. Checkpoint/restart (c/r) will want time virtualization (Daniel)
>> > 	8. C/r will want inode virtualization (Daniel)
>> 
>> What is the status on device namespace/virtualization ?  the first few
>> I have in mind are per-container: /dev/rtc, /dev/ttyX, and even
>> dev/urandom (isolated entropy pools?).
>
> They sound like good ideas.  I think the status is unstarted :)
>
>> The first two are important for containers that hold user sessions
>> (e.g. linux terminal server) - is anyone pushing this use-case in the
>> context of containers-end-game ?
>
> /me hopes someone chimes in and says "I am".
>
> BTW, containers end-game is off the ksummit agenda now.

I am still slowly poking at the sysfs cleanups/changes.

For me the priorities are rougly:
- bug fixes in the existing namespaces
- sysfs cleanups
- sysfs for the network namespace ( and likely others )
- a complete user namespace (I am tired of running everything as root).

I have a bunch of generally unrelated hotplug changes I am working on as
well.

Now that the network namespace has stabalized I am hoping to have a bit more
time for the others.

Eric