> On Feb. 28, 2015, 5:03 p.m., Jay Buffington wrote: > > src/slave/containerizer/mesos/launch.cpp, line 262 > > <https://reviews.apache.org/r/31444/diff/1/?file=876502#file876502line262> > > > > I was curious how you came up with this list. I did "man MAKEDEV" and > > read this: > > > > Certain devices are required for minimal functionality. These > > are: > > mem - access to physical memory; null - null device (infinite > > sink); port - access to I/O ports; zero - null byte source (infinite > > source); core - symlink to /proc/kcore (for kernel debugging); full - > > always returns ENOSPACE on write; ram - ramdisk; tty - to access the > > controlling tty of a process. > > Ian Downes wrote: > Based off those created by systemd's nspawn utility. I don't want to > expose mem, kmem, ram, or kcore unless there's a demonstrated need (at which > point this should be refactored so it's configurable).
+1 > On Feb. 28, 2015, 5:03 p.m., Jay Buffington wrote: > > src/slave/containerizer/mesos/launch.cpp, line 376 > > <https://reviews.apache.org/r/31444/diff/1/?file=876502#file876502line376> > > > > A DEBUG message here explaining that the process is chroot'ing would be > > useful in the logs. Without it subsequent error messages like "Failed to > > chdir into work directory /tmp/mesos" are super confusing when reading the > > logs. > > Ian Downes wrote: > I agree that it would be confusing but one concern with logging the > chroot path is that these are user visible logs and we'd be exposing host > information. Thoughts? Well, I think your problem here is that these are user visible logs :) The requirement that we can't log operator useful information because users might see it seems (IMHO) preposterous. (I'm assuming you're talking about the fact that users fetch mesos-slave.out.log via the web ui?) Maybe users should only be able to see INFO and higher log messages? And we log this at a DEBUG level? - Jay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31444/#review74674 ----------------------------------------------------------- On Feb. 25, 2015, 10:48 p.m., Ian Downes wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/31444/ > ----------------------------------------------------------- > > (Updated Feb. 25, 2015, 10:48 p.m.) > > > Review request for mesos, Chi Zhang, Dominic Hamon, Jay Buffington, and Jie > Yu. > > > Bugs: MESOS-2350 > https://issues.apache.org/jira/browse/MESOS-2350 > > > Repository: mesos > > > Description > ------- > > Optionally take a path that the launch helper should chroot to before > exec'ing the executor. It is assumed that the work directory is mounted to > the appropriate location under the chroot. In particular, the path to the > executor must be relative to the chroot. > > Configuration that should be private to the chroot is done during the launch, > e.g. mounting proc and statically configuring basic devices. It is assumed > that other configuration, e.g., preparing the image, mounting in volumes or > persistent resources, is done by the caller. > > Mounts can be made to the chroot (e.g., updating the volumes or persistent > resources) and they will propagate in to the container but mounts made inside > the container will not propagate out to the host. > > It currently assumes that at least {{chroot}}/tmp is writeable and that mount > points {{chroot}}/{tmp,dev,proc,sys} exist in the chroot. > > This is specific to Linux. > > > Diffs > ----- > > src/slave/containerizer/mesos/launch.hpp > 7c8b535746b5ce9add00afef86fdb6faefb5620e > src/slave/containerizer/mesos/launch.cpp > 2f2d60e2011f60ec711d3b29fd2c157e30c83c34 > > Diff: https://reviews.apache.org/r/31444/diff/ > > > Testing > ------- > > Manual testing only so far. This is harder to automate because we need a > self-contained chroot to execute something in... Suggestions welcome. > > > Thanks, > > Ian Downes > >
