Hello Oren, Oren Laadan wrote: > Cedric Le Goater wrote: >> Hello All, >> >> Some of us will meet next week for the first mini-summit on containers. >> Many thanks to Alasdair Kergon and LCE for the help they provided in >> making this mini-summit happen ! >> >> It will be help on Monday the 3rd of September from 9:00 to 12:45 at LCE >> in room D. We also might get a phone line for external participants and, >> if not, we should be able to set up a skype phone. >> >> Here's a first try for the Agenda. >> >> Global items >> >> [ let's try to defer discussion after presentation ] >> >> * Pavel Emelianov status update >> * Serge E. Hallyn Container Roadmap including >> . task containers (Paul Menage) >> . resource management (Srivatsa Vaddagiri) >> >> Special items >> >> [ brainstorm sessions which we would like to focus on ] >> >> * builing the global container object ('a la' openvz or vserver) >> * container user space tools >> * container checkpoint/restart > > 5. checkpoint/restart > memory c/r > (there are a few designs and prototypes) > (though this may be ironed out by then) > per-container swapfile? > overall checkpoint strategy (one of:) > in-kernel > userspace-driven > hybrid > overall restart strategy > use freezer API > use suspend-to-disk? > > sysvipc > "set identifier" syscall > pid namespace > clone_with_pid() > There are other identifiers - pseudo terminals, message queues (mq) right, we have plans for developing these if needed (cf 2.) > (if you insist on supporting these ...). In general, we need a way > to specify the virtual id of a resource that is created. right, pierre peiffer has sent such a pachset for the sysvipc namespace. I'm looking at a clone_with_pid() for pid namespace. > I suggest > that this should be part of an interface between c/r and containers > (see below) > > live migration > aka pre-copy (which can be used for live migration but also to reduce > the downtime due to a checkpoint). yes that's usually what the buzz term "live migration" is used for. > how about adding incremental checkpoint to the list ? sure. I think it's a bit early to address these topic but we should have them in mind as some implementations already exist. And we need to gather all the needs. > I think that it is also important to discuss an interface between c/r and > containers, each of which stands on it own. For instance, how to request > a specific virtual id (during restart), define required notifiers (to > set/unset c/r related data on/off a task), control c/r-related setting of > container (e.g. frozen, restarting) that may affect behavior, such as > signal handling, and so forth. This is exactly what we want to talk about. We need to identify these C/R needs, talk and agree about possible APIS and then convince the linux subsystem maintainers that they are useful for a large set of C/R solutions based on containers. > Also, such an interface can allow existing c/r implementations to work with > different virtualization implementations as they become available. what you call "virtualization" (private identifier namespaces), is I think being covered by the namespaces. These namespaces are not complete (like we're missing a way to reassign ids) but they are going in the right direction, IMO. However, I don't think there will be different "virtualization" implementations in mainline. > Many of these were discussed in a recent Zap paper present in USENIX: > http://www.ncl.cs.columbia.edu/publications/usenix2007_fordist.pdf > The paper describes important design choices in Zap (but I'm biased ...). > I think it may serve as an appetizer for the discussion :P Thanks, I hope we all have time to read it. C. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers