On Sun, 16.06.13 15:15, Tejun Heo (tj@xxxxxxxxxx) wrote: > We want composability regardless of migration, but as for migration > itself, an alternative could be having an atomic "move everything in > cgroup A to cgroup B" interface, so that the admin (whether human or > base system software) can set up a new cgroup and then move the member > tasks atomically. I am not sure this would cut it for containers. For containers we'll usually have a fully populated cgroup subtree, and if we want to migrate that somewhere else, then we'd something that works recursively and allows us to not tell the container at all about the move (i.e. the namespace of cgroupfs the container sees should ideall stay entirely unaltered by the move). Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
