> On July 17, 2017, 5:12 p.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
> ```
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'.
- Jie
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60888/#review180694
-----------------------------------------------------------
On July 15, 2017, 12:40 a.m., Joseph Wu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60888/
> -----------------------------------------------------------
>
> (Updated July 15, 2017, 12:40 a.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
>
>
