[
https://issues.apache.org/jira/browse/MESOS-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15309963#comment-15309963
]
Guangya Liu commented on MESOS-5465:
------------------------------------
Did some investigation for this, currently, when using volume to be an image,
the mesos containerizer will mount the `rootfs` at `continer_path`, the `mode`
of the `container_path` is controlled by a framework developer, we may not able
to create the `manifest` file directly under the `container_path` if the
`conatiner_path` is readonly.
The `rootfs` for a volume image can be prepared in three ways: {{copy}},
{{bind}} and {{overlay}}, so a possible solution for this is when prepare the
rootfs, just add the `manifest` to the `rootfs` and when bind mount the
`rootfs` to `container_path`, the `manifest` will be there. The problem for
this solution is that all of the container `rootfs` will include a `manifest`
file even if the `rootfs` is not for a volume.
[~jieyu] any comments for this? Thanks.
> Container image as a volume source should also include image manifest.
> ----------------------------------------------------------------------
>
> Key: MESOS-5465
> URL: https://issues.apache.org/jira/browse/MESOS-5465
> Project: Mesos
> Issue Type: Bug
> Reporter: Jie Yu
> Assignee: Guangya Liu
>
> Currently, if a user specifies the source of a volume to be an image (e.g.,
> Docker image), we only prepare the rootfs and mount it at 'container_path' in
> the container.
> However, the rootfs itself is not sufficient to allow the executor to launch
> the docker container. We need the docker manifest as well to get the env,
> entry point, cmd information.
> One solutions is to make container_path a directory containing two things: 1)
> rootfs, 2) manifest. But this is a breaking change, we might need to
> introduce a deprecation cycle for that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
