[
https://issues.apache.org/jira/browse/MESOS-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552237#comment-16552237
]
Qian Zhang commented on MESOS-7947:
-----------------------------------
{quote}With 2) all those executors that use LAUNCH_NESTED_CONTAINER can just
set a boolean field indicating that they want the container's sandbox to be
GC'ed.
{quote}
Currently LAUNCH_NESTED_CONTAINER is handled by containerizer but GC is handled
the agent, so if we add a GC related field in LAUNCH_NESTED_CONTAINER,
containerizer will know such field but it is not supposed to handle such field,
and agent will not know such field (actually agent is not aware of the
LAUNCH_NESTED_CONTAINER API call). Or we want containerizer to do the GC for
nested container by calling `GarbageCollector::schedule()`?
{quote}One limitation of 2) is that it only applies to executors that leverage
LNC to launch tasks. For multi-task executors that don't use that (e.g., long
lived executor in our tests), it doesn't apply.
{quote}
It seems option 1) can handle this case. I mean if we add an optional field in
TaskInfo (something like GCPolicy), the executor can do the GC for the task
either by calling REMOVE_CONTAINER (for the nested container case) or doing the
GC itself (for the case that the task is launched by the executor itself).
> Add GC capability to nested containers
> --------------------------------------
>
> Key: MESOS-7947
> URL: https://issues.apache.org/jira/browse/MESOS-7947
> Project: Mesos
> Issue Type: Improvement
> Components: executor
> Reporter: Chun-Hung Hsiao
> Assignee: Joseph Wu
> Priority: Major
>
> We should extend the existing API or add a new API for nested containers for
> an executor to tell the Mesos agent that a nested container is no longer
> needed and can be scheduled for GC.
> Related issue: MESOS-7939
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
