There are various use cases where running a full pod (with all of the isolation and lifecycle that implies) isn't desirable and users simply want to perform a "simpler" execution of a container image. In the simplest case this is just using rkt as a package manager - discovering/downloading/extracting an image onto the filesystem, chrooting in, and execing the desired executable. The rkt fly prototype (#1072, #1416) implements a very basic example of this.

Obviously in this mode there is (aside from the filesystem) no isolation whatsoever, in terms of either resources or namespaces - it is just another process executing directly on the host. But different users may have more nuanced requirements, like sharing some namespaces and not others with the host. One example is #1046 about using the host's PID namespace. Another use case would be running the CNI networking plugins using rkt, rather than bundling them into it as is done today. system-nspawn's --share-system flag provides one other example of a possible execution mode that might be desirable.

This is a tracker ticket to start fleshing out some example use cases and design work.