[
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)
