Serge E. Hallyn wrote: > Quoting Kir Kolyshkin (kir@xxxxxxxxxx): > >> Serge E. Hallyn wrote: >> >>> Hi, >>> >>> here is a list of topics which I believe people are interested in >>> writing papers on. I'm listing names of those who I think are >>> interested in writing them. Sorry if I leave anyone off of a topic >>> they're interested in. However it seems to me it would be best if we >>> can agree on one person or two people to drive each topic, so everyone >>> doesn't sit around expecting someone else to submit the abstract. >>> >>> Am I missing any? >>> >>> mini-summit: >>> I will submit for a 1-day mini-summit. Some interesting >>> remaining topics for the mini-summit would include device >>> namespaces, ttys and syslog, and lots of checkpoint/restart. >>> >>> >> That's right, obviously the title of the mini-summit would be something >> like "Linux Kernel Containers". >> > > Attached is what I currently had for a proposal to send to the OLS > committee. (Please feel free to edit and add to the wiki) > Looks really good from the first glance. I put it to wiki as http://wiki.openvz.org/Containers/Mini-summit_2008/Proposal and hope we will take a closer look tomorrow (as it's 3am here now:)). > I just took guesses at moderator names because the OLS CFP asks for > them. If someone else (Kir? Cedric?) wants to moderate the namespaces > part that's fine with me. > > >>> Does anyone think we don't need one of these at ols? Or that >>> we do? >>> >>> Is anyone interested in organizing the summit - coming out >>> with an agenda, sending out announcements, etc - either >>> alone or with my help? >>> >>> >> Guess I can help a bit with organizing this. To that effort, I have put >> up a wiki page: >> http://wiki.openvz.org/Containers/Mini-summit_2008 >> > > Cool, thanks. > > >> We also need to have some kind of a list of attendees. So far I came >> with 12 names listed on that page, please feel free to edit/add more. >> >>> pidns: (Pavel and Suka) >>> I've heard it called a tutorial, though I think some of the >>> technical details are interesting in and of themselves. Its >>> also an important area to make sure other developers - i.e >>> people working with flocks or kthreads - understand. >>> >>> >> This is the proposal Pavel filed today, it is editable so we can improve >> it, please send your suggestion/fixes. >> >> >>> PID namespaces in the Linux kernel >>> >>> PID namespaces is a relatively new Linux kernel feature merged in >>> > > Hmm... "PID namespaces are a relatively new Linux kernel feature" > sounds more normal. Though I'm not sure which is more "correct" > Thanks! Fixed. > >>> 2.6.24 kernel. It is a "view" of a particular set of tasks on the >>> system. PID namespaces work in a similar way to filesystem namespaces: >>> a process can be accessed in multiple namespaces, but it may have a >>> different name in each. It is one of the building blocks for >>> containers virtualization, and a prerequisite for >>> checkpointing/restart and live migration. >>> >>> The paper outlines some implementation details, explains user space >>> constraints that may seem odd, and discusses the impact of the feature >>> on the kernel APIs. >>> >>> In collaboration with Sukadev Bhattiprolu, IBM. >>> > > Looks good to me. > Great, thanks! > >> >>> netns: denis driving, daniel, benjamin >>> >>> >> Right, Den Lunev, Daniel Lezcano, Pavel Emelyanov and Benjamin Thery. >> Den already filed a proposal for a paper/talk, here is how it looks >> like. Again, it is editable, so send your improvements. >> >> >>> Network namespace for Linux >>> >>> The paper outlines the effort to implement a network virtualization in >>> the Linux kernel. This is a part of on-going effort to bring the >>> containers functionality into Linux. A container is an isolated >>> user-space partition, which performs like a stand-alone server, with >>> multiple containers co-existing on a single Linux box. Containers can >>> be used for resource management, network security and in >>> high-performance computing. >>> >>> Making several instances of the Linux network stack, based on the >>> namespace concept, is a big challenge, but it is required to build a >>> full featured container. We will show how to configure and use a new >>> instance of the network stack, how the feature is architectured and >>> implemented, and what is the current state of the art. >>> >>> In collaboration with Daniel Lezcano, IBM, Benjamin Thery, Bull, and >>> Pavel Emelyanov, OpenVZ. >>> >>>> >>>> >>> namespaces status: Pavel and Cedric >>> There was no ns status update last year it may be of >>> interest. Instead of a separate pidns paper, pidns could >>> also be mentioned here. >>> >>> >> What if we organise a BoF, outlining the current status and future >> directions. Something like "Linux Kernel Containers development status" >> or some better title. I'd say "Containers" here instead of "Namespaces" >> (or use "Containers/Namespaces") because containers is easier term from >> my PoV. >> > > That has a different effect. A BoF would also be good, but if there are > parts about the direction with namespaces about which we want some > guidance from the community (which I think there are - sysfs, namespace > entering, checkpoint/restart in general) then we may get more people at > a paper talk than a bof. A Bof will basically get people particularly > interested in either using or developing the feature. > Makes sense indeed. My primary concern about talk vs. BoF was/is -- do we have enough quality material/content to write a "minimum of 6 pages and a maximum of 15 pages (properly formatted)" paper which is required for a talk (but not for a BoF). Well, a lot has happened since last year, maybe enough for a paper. > >>> namespace entering: Cedric and serge? >>> This *probably* isn't enough for a full paper. So it could >>> go under namespace status paper. But there is quite a bit >>> to say just by listing the existing proposed solutions (at >>> least 4 I can think of offhand) and their shortcomings. >>> >>> memory c/r: Dave Hansen, serge interested >>> I suspect many people on this list have their own ideas on >>> how to go about the checkpoint and restart. I suppose they >>> could each write their own paper, or work together on a single >>> combined paper laying out the possibilities >>> >>> >> Actually we already followed that way -- Andrey Mirkin has filed a >> paper/talk proposal today, titled "Containers checkpointing and live >> migration". Guess Dave (and/or Oren Laadan, and/or Cedric, maybe >> somebody else as well) could come with their own talks/papers as well. >> >> Still can't make up my mind if we need a BoF on the subject or not. >> > > I figure at least a third of the mini-summit will be c/r. Separate > papers may actually be the way to go, so long as each paper presents a > different approach. OLS could put them all together in one block. Then > at a BoF or a beer bof, after all have been presented and everyone has > heard all the arguments, we can discuss the way to go forward. > Sounds like a plan, especially the beer part ;) > >>> user namespace approaches: serge >>> >>> cgroups and containers: Paul Menage driving?, Balbir? >>> A cgroups update could either be its own paper or joined >>> with the namespaces status paper. >>> >>> Paul were you considering a separate paper to discuss >>> the cgroups and namespace management as laid out in >>> your Sep 03 2007 email "Thoughts on Namespace / Subsystem >>> unification"? >>> >>> >> Not too much stuff about resource management, i.e. user memory >> controller, kernel memory controller, other per-namespace limits etc. Or >> is it all covered by cgroups? Or it's not what we are currently targeting? >> > > I was figuring that each of those cgroups wouldn't have enough material > for a paper and yes i figured one cgroup paper would be about the > various cgroups. But I'm pretty far out of touch with that work so > coudl be completely off base. The 'ns/cgroup > unification'/administration topic is the one that interests me the most > out of that block :) > > thanks, > -serge > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers