You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Gilbert Song (JIRA)" <ji...@apache.org> on 2016/10/11 23:28:20 UTC

[jira] [Created] (MESOS-6371) Remove the 'recover()' interface in 'ContainerLogger'.

Gilbert Song created MESOS-6371:
-----------------------------------

             Summary: Remove the 'recover()' interface in 'ContainerLogger'.
                 Key: MESOS-6371
                 URL: https://issues.apache.org/jira/browse/MESOS-6371
             Project: Mesos
          Issue Type: Improvement
          Components: containerization
            Reporter: Gilbert Song
            Assignee: Gilbert Song


This issue arises from the nested container support in Mesos.

Currently, the container logger interface mainly contains `recover()` and `prepare()` methods. The `prepare` will be called in containerizer::launch() to launch a container, while `recover` will be called in containerizer::recover() to recover containers. Both methods rely on 2 parameters: ExecutorInfo and sandbox directory. The sandbox directory for nested containers can still be passed to the logger. However, because of nested container support, ExecutorInfo is no longer available for nested containers.

In logger prepare, the ExecutorInfo is used for deliver FrameworkID, ExecutorID, and Label for custom metadata. In containerizer launch, we can still pass the ExecutorInfo of a nested container's top level parent to the logger, so that those information will not be lost.

In logger recover, since currently the logger is stateless, and most of the logger modules are doing `noop` in logger::recover(). The recover interface should exist together with `cleanup` method if the logger become stateful in the future. To avoid adding tech debt in containerizer nested container support, we should remove the `recover` in container logger for now (can add it back together with `cleanup` in the future if the container logger become stateful).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)