You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Pierre Cheynier (JIRA)" <ji...@apache.org> on 2017/01/26 16:43:24 UTC
[jira] [Updated] (MESOS-7007) filesystem/shared and
--default_container_info broken since 1.1
[ https://issues.apache.org/jira/browse/MESOS-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre Cheynier updated MESOS-7007:
-----------------------------------
Description:
I face this issue, that prevent me to upgrade to 1.1.0 (and the change was consequently introduced in this version):
I'm using default_container_info to mount a /tmp volume in the container's mount namespace from its current sandbox, meaning that each container have a dedicated /tmp, thanks to the {{filesystem/shared}} isolator.
I noticed through our automation pipeline that integration tests were failing and found that this is because /tmp (the one from the host!) contents is trashed each time a container is created.
Here is my setup:
* {{--isolation='cgroups/cpu,cgroups/mem,namespaces/pid,*disk/du,filesystem/shared,filesystem/linux*,docker/runtime'}}
* {{--default_container_info='\{"type":"MESOS","volumes":\[\{"host_path":"tmp","container_path":"/tmp","mode":"RW"\}\]\}'}}
I discovered this issue in the early days of 1.1 (end of Nov, spoke with someone on Slack), but had unfortunately no time to dig into the symptoms a bit more.
I found nothing interesting even using GLOGv=3.
Maybe it's a bad usage of isolators that trigger this issue ? If it's the case, then at least a documentation update should be done.
Let me know if more information is needed.
was:
I face this issue, that prevent me to upgrade to 1.1.0 (and the change was consequently introduced in this version):
I'm using default_container_info to mount a /tmp volume in the container's mount namespace from its current sandbox, meaning that each container have a dedicated /tmp, thanks to the {filesystem/shared} isolator.
I noticed through our automation pipeline that integration tests were failing and found that this is because /tmp (the one from the host!) contents is trashed each time a container is created.
Here is my setup:
* {{--isolation='cgroups/cpu,cgroups/mem,namespaces/pid,*disk/du,filesystem/shared,filesystem/linux*,docker/runtime'}}
* {{--default_container_info='\{"type":"MESOS","volumes":\[\{"host_path":"tmp","container_path":"/tmp","mode":"RW"\}\]\}'}}
I discovered this issue in the early days of 1.1 (end of Nov, spoke with someone on Slack), but had unfortunately no time to dig into the symptoms a bit more.
I found nothing interesting even using GLOGv=3.
Maybe it's a bad usage of isolators that trigger this issue ? If it's the case, then at least a documentation update should be done.
Let me know if more information is needed.
> filesystem/shared and --default_container_info broken since 1.1
> ---------------------------------------------------------------
>
> Key: MESOS-7007
> URL: https://issues.apache.org/jira/browse/MESOS-7007
> Project: Mesos
> Issue Type: Bug
> Components: agent
> Affects Versions: 1.1.0
> Reporter: Pierre Cheynier
>
> I face this issue, that prevent me to upgrade to 1.1.0 (and the change was consequently introduced in this version):
> I'm using default_container_info to mount a /tmp volume in the container's mount namespace from its current sandbox, meaning that each container have a dedicated /tmp, thanks to the {{filesystem/shared}} isolator.
> I noticed through our automation pipeline that integration tests were failing and found that this is because /tmp (the one from the host!) contents is trashed each time a container is created.
> Here is my setup:
> * {{--isolation='cgroups/cpu,cgroups/mem,namespaces/pid,*disk/du,filesystem/shared,filesystem/linux*,docker/runtime'}}
> * {{--default_container_info='\{"type":"MESOS","volumes":\[\{"host_path":"tmp","container_path":"/tmp","mode":"RW"\}\]\}'}}
> I discovered this issue in the early days of 1.1 (end of Nov, spoke with someone on Slack), but had unfortunately no time to dig into the symptoms a bit more.
> I found nothing interesting even using GLOGv=3.
> Maybe it's a bad usage of isolators that trigger this issue ? If it's the case, then at least a documentation update should be done.
> Let me know if more information is needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)