mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Mahler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MESOS-6214) Containerizers assume caller will call 'destroy' if 'launch' fails.
Date Tue, 03 Oct 2017 18:46:00 GMT

    [ https://issues.apache.org/jira/browse/MESOS-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16190131#comment-16190131
] 

Benjamin Mahler commented on MESOS-6214:
----------------------------------------

[~vinodkone] [~klueska] I'll re-open this, since the commit description included here does
not look like a fix for this issue:

{quote}
Once we remove
the requirement for `destroy()` to be called explicitly after launch
failures, we should move this check back to the top of this function.
{quote}

> Containerizers assume caller will call 'destroy' if 'launch' fails.
> -------------------------------------------------------------------
>
>                 Key: MESOS-6214
>                 URL: https://issues.apache.org/jira/browse/MESOS-6214
>             Project: Mesos
>          Issue Type: Task
>          Components: containerization
>            Reporter: Benjamin Mahler
>            Assignee: Kevin Klues
>              Labels: tech-debt
>             Fix For: 1.2.0
>
>
> The planned API for nested containers is to allow launching, waiting (for termination),
and killing (currently only SIGKILL) of the nested container. Note that this API provides
no mechanism for "cleaning up" the container because it will implicitly do so once the container
terminates.
> However, the containerizer currently assumes that the caller will call destroy if the
launch fails. In order to implement the agent's API for managing nested containers, we will
have to set up a failure continuation to call destroy to ensure the cleanup occurs correctly.
> Ideally, the API of the containerizer does not require the caller to call destroy after
a launch failure, given that the launch did not succeed it seems counter-intuitive for the
responsibility of clean up to be on the caller. In addition, in the container termination
case, the containerizer will implicitly clean up (so this seems inconsistent as well).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message