"Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > Quoting Oren Laadan (orenl@xxxxxxxxxxx): >> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
