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) (if you insist on supporting these ...). In general, we need a way to specify the virtual id of a resource that is created. 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). how about adding incremental checkpoint to the list ? 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. Also, such an interface can allow existing c/r implementations to work with different virtualization implementations as they become available. 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 Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers