> On July 31, 2013, 6:41 p.m., Matthew Farrellee wrote: > > Non-code comment from the peanut gallery - technically cgroups and > > namespaces are separate. You get the benefits of killing an entire group of > > processes w/ cgroups and get group stats (mem, cpu, blk), but you don't get > > the isolation (signal sending, pid 1). You get the isolation benefit from > > namespaces, but not group stats. To help avoid confusing others in the > > future, consider making this the namespace_isolator. > > Ian Downes wrote: > We're just starting to rework the isolator abstraction to address these > concerns, see https://issues.apache.org/jira/browse/MESOS-600 > > Eric Biederman wrote: > Most of the namespaces also have statistics associated with them as well. > > I may be blind but I have yet to see how a cgroup can be used to kill a > group of processes. cgroups just seem to list the tasks that are members of > the cgroup. > > cgroups do give you a different kind of isolation than namespaces. The > namespaces keep you from seeing the other guy. cgroups if setup properly > keep you from using the other guys cpu or memory. > > I do agree that the naming is confusing. My inclination is to change the > name of the file and the concept to the linux_isolator rather than the cgroup > isolator. > > Is there a concern that the pid namespace will break peoples current > configurations? If there is a problem this code will need a policy knob. It > is my hope that people aren't sending signals to processes outside of their > sandbox and we can use code that has been in the kernel since 2.6.24 without > a policy knob. > > The reason I called out killing the group in my description is that the > current code to kill a cgroup is currently challenged and it is probably that > we could greatly simplify things and make them more reliable with the use of > a pid namespace. > > > Matthew Farrellee wrote: > The best summary I know of that describes process tracking issues in a > batch system is BrianB's at > > > http://osgtech.blogspot.com/2011/06/how-your-batch-system-watches-your.html > > It covers the long history and experiences of doing this in the HTCondor > system. > > I would hope that using pid namespace would not break current > configurations. Applications that are overly conservative may not like > running with a small pid -- crazy I agree, but it has happened. > > If you make the isolator/executor modular enough it could have value to > other projects that are trying to do this same type of isolation and > monitoring. Unfortunately, no one seems to have a modular solution you could > just crib.
There is no reason you can't/shouldn't do both, with admin config control. - Timothy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13045/#review24364 ----------------------------------------------------------- On July 29, 2013, 10:52 p.m., Eric Biederman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13045/ > ----------------------------------------------------------- > > (Updated July 29, 2013, 10:52 p.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, Ian Downes, and Vinod > Kone. > > > Repository: mesos-git > > > Description > ------- > > cgroup_isolator: Isolate the exectuor and tasks in a pid namespace. > > This has several advantages: > > - It becomes impossible to send unix signals to processes outside of > the pid namespace. > > - Forked processes can not escape the pid namespace no matter what they do. > > - It becomes easy to cleanup a pid namespace because all processes are > killed when the first process the executor is killed. > > > Diffs > ----- > > src/slave/cgroups_isolator.cpp 0faf7d5 > > Diff: https://reviews.apache.org/r/13045/diff/ > > > Testing > ------- > > make -j 8 check > > And watched the tests pass. > > > Thanks, > > Eric Biederman > >
