> On July 17, 2017, 10:12 a.m., Jie Yu wrote: > > src/slave/paths.hpp > > Lines 56-57 (patched) > > <https://reviews.apache.org/r/60888/diff/1/?file=1777224#file1777224line56> > > > > If we want to completely decouple containerizer from agent (the goal) > > in the future, i think the container sandbox should be under it's own > > hierarchy? > > > > To be backwards compatible, we can only do that for standalone > > containers first. Ultimately, the agent's directory can use a symlink to > > the real container's sandbox i think. > > Joseph Wu wrote: > So are you thinking something like this? > ``` > root ('--work_dir' flag) > + |-- standalone > + | |-- <container_id> (sandbox) > |-- slaves > | |-- latest (symlink) > | |-- <slave_id> > | |-- frameworks > | |-- ... > + | |-- <symlink to standalone directory> > |-- meta > |-- slaves > | |-- ... > + |-- standalone > + |-- forked.pid > ``` > > Jie Yu wrote: > We have `work_dir` (persist across reboot) and `runtime_dir` (does not > persist across reboot). Note that these two directories will be in differnet > location most likely, but operator might specify them to the be same (e.g., > for testing). > > I was thinking something like this: > ``` > <work_dir> > |-- sandboxes > |-- <container_id> > ... > |-- slaves > |-- latest (symlink) > |-- <slave_id> > |-- ... > |-- meta > |-- ... > ``` > > I was thinking that there will be a separate component to manage > standalone containers (DaemonManager). Its state should be in `<runtime_dir>` > (no need to persist across reboot?), and should not tied to 'agent'.
Summary of offline discussion: * Standalone container sandboxes will live at the top level of the work directory under `sandboxes/<container_id>`. * We should refactor containerizer recovery logic so that it takes a set of ContainerStates which are "recoverable" rather than the SlaveState blob. * Standalone containers will need a marker file (empty) in the runtime directory so that the containerizer knows to recover it. When a DaemonManager (or thing which manages standalone containers) is added in future, we'll stop relying on this marker file. - Joseph ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/60888/#review180694 ----------------------------------------------------------- On July 14, 2017, 5:40 p.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/60888/ > ----------------------------------------------------------- > > (Updated July 14, 2017, 5:40 p.m.) > > > Review request for mesos, Gilbert Song and Jie Yu. > > > Bugs: MESOS-7305 > https://issues.apache.org/jira/browse/MESOS-7305 > > > Repository: mesos > > > Description > ------- > > Although there is no way to launch standalone containers yet, > this commit outlines the expected layout of container metadata > which should be populated when launching standalone containers. > > The layout is fairly simple, as standalone containers have no > framework, executor, or tasks to worry about. The sandbox and > metadata directories for standalone containers will be nested under > `slaves/<SlaveID>/standalone/<ContainerID>`. > > In terms of metadata, standalone containers only checkpoint their > forked PID at the moment. > > > Diffs > ----- > > src/slave/containerizer/mesos/containerizer.cpp > 9376d14d66f5dc7e91c7c0e9da253f5eb9347539 > src/slave/paths.hpp 51b481fc0870f1e95448f85ee2fd485fceea1919 > src/slave/paths.cpp c08e83c14be30c9ef376326d23a8ec6b6b9ff246 > src/slave/state.hpp 18c43193349ca6ec3d18967dcee69324a435e2fa > src/slave/state.cpp 24efd4b108ec292223016151d01b10ff2c7f75ca > > > Diff: https://reviews.apache.org/r/60888/diff/1/ > > > Testing > ------- > > See next patch and later ones too. > > > Thanks, > > Joseph Wu > >
