You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Benjamin Bannier (JIRA)" <ji...@apache.org> on 2015/10/19 15:34:05 UTC

[jira] [Commented] (MESOS-3709) Modulize the containerizer interface.

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

Benjamin Bannier commented on MESOS-3709:
-----------------------------------------

There seem to be an straight-forward and a more involved part in moving {{Containerizer}} to the public interface:

# streamline {{Containerizer}} interface: demote {{Containerizer::create}} and {{Containerizer::resources}} from member functions to free functions, and
# decide on a publishable signature for {{Containerizer::recover}}.


Currently we have {{Containerizer::recover(const Option<state::SlaveState>&)}} where {{SlaveState}} is not part of the public interface. The various concrete containerizers use {{state}} to obtain mostly {{FrameworkStates}}, or {{ExecutorStates}} from which they get {{ContainerIDs}}. Often the {{RunState}} belonging to a {{ContainerID}} is looked up in an {{ExecutorState}}.
The {{DockerContainerizer}} additionally uses the {{StateIDs}} (i.e. {{SlaveState::id}}) which it stores as {{Container::slaveIDs}}.

It seems we wouldn't want to publish all the dependencies of {{SlaveState}} and maintain migration code for their internal serialization via protobuf. Instead we should probably decide on a less open set using public types a caller needs to provide when invoking {{Containerizer::recover}}; we could then refactor existing containerizers to that interface.  

> Modulize the containerizer interface.
> -------------------------------------
>
>                 Key: MESOS-3709
>                 URL: https://issues.apache.org/jira/browse/MESOS-3709
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: Jie Yu
>            Assignee: Benjamin Bannier
>
> So that people can implement their own containerizer as a module. That's more efficient than having an external containerizer and shell out. The module system also provides versioning support, this is definitely better than unversioned external containerizer.



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