You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Joseph Wu <jo...@mesosphere.io> on 2018/07/19 12:59:09 UTC
Review Request 67972: RFC: Added RetentionPolicy for task metadata and
sandboxes.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67972/
-----------------------------------------------------------
Review request for mesos, Gilbert Song, Qian Zhang, and Vinod Kone.
Bugs: MESOS-6285 and MESOS-7947
https://issues.apache.org/jira/browse/MESOS-6285
https://issues.apache.org/jira/browse/MESOS-7947
Repository: mesos
Description
-------
This adds a protobuf which tells the agent to garbage collect
more directories than it currently does. The agent currently garbage
collects directories at the executor level, which is not ideal for
certain types of long-lived executors that launch many tasks or
nested containers over its lifetime.
Each task launched under the same executor will result in a checkpointed
TaskInfo in the agent's metadata. This can result in slow agent
recovery, as described in MESOS-6285, where an excessive number of tasks
will actually cause the agent to be OOM-killed.
For the default executor, each task will be launched as a nested
container, which will include a sandbox directory (under the executor's
sandbox). If too many nested containers are launched without removing
the associated sandboxes, the agent may run out of disk space.
Diffs
-----
include/mesos/agent/agent.proto 74488e873cbf99ca487403b70691912cf3788288
include/mesos/mesos.proto 5a985fca39cdfb7e9b4775650a7e5dbe68c3b8ae
Diff: https://reviews.apache.org/r/67972/diff/1/
Testing
-------
Thanks,
Joseph Wu
Re: Review Request 67972: RFC: Added RetentionPolicy for task
metadata and sandboxes.
Posted by Mesos Reviewbot Windows <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67972/#review206239
-----------------------------------------------------------
PASS: Mesos patch 67972 was successfully built and tested.
Reviews applied: `['67972']`
All the build artifacts available at: http://dcos-win.westus.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/1956/mesos-review-67972
- Mesos Reviewbot Windows
On July 19, 2018, 12:59 p.m., Joseph Wu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67972/
> -----------------------------------------------------------
>
> (Updated July 19, 2018, 12:59 p.m.)
>
>
> Review request for mesos, Gilbert Song, Qian Zhang, and Vinod Kone.
>
>
> Bugs: MESOS-6285 and MESOS-7947
> https://issues.apache.org/jira/browse/MESOS-6285
> https://issues.apache.org/jira/browse/MESOS-7947
>
>
> Repository: mesos
>
>
> Description
> -------
>
> This adds a protobuf which tells the agent to garbage collect
> more directories than it currently does. The agent currently garbage
> collects directories at the executor level, which is not ideal for
> certain types of long-lived executors that launch many tasks or
> nested containers over its lifetime.
>
> Each task launched under the same executor will result in a checkpointed
> TaskInfo in the agent's metadata. This can result in slow agent
> recovery, as described in MESOS-6285, where an excessive number of tasks
> will actually cause the agent to be OOM-killed.
>
> For the default executor, each task will be launched as a nested
> container, which will include a sandbox directory (under the executor's
> sandbox). If too many nested containers are launched without removing
> the associated sandboxes, the agent may run out of disk space.
>
>
> Diffs
> -----
>
> include/mesos/agent/agent.proto 74488e873cbf99ca487403b70691912cf3788288
> include/mesos/mesos.proto 5a985fca39cdfb7e9b4775650a7e5dbe68c3b8ae
>
>
> Diff: https://reviews.apache.org/r/67972/diff/1/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Joseph Wu
>
>