[jira] [Commented] (MESOS-9009) Support for creation non-existing host paths in a whitelist as source paths
[
https://issues.apache.org/jira/browse/MESOS-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776466#comment-16776466
]
Jason Lai commented on MESOS-9009:
--
Added a new patch for documentation: https://reviews.apache.org/r/70048/
[~gilbert] could you help merge it?
> Support for creation non-existing host paths in a whitelist as source paths
> ---
>
> Key: MESOS-9009
> URL: https://issues.apache.org/jira/browse/MESOS-9009
> Project: Mesos
> Issue Type: Task
> Components: containerization
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Major
> Labels: containerizer, mount, path
> Fix For: 1.8.0
>
>
> Docker creates a directory specified in {{docker run}}'s {{--volume}}/{{-v}}
> option as the source path that will get bind-mounted into the container, if
> the source location didn't originally exist on the host.
> Unlike Docker, UCR bails on launching containers if any of their host mount
> paths doesn't originally exist. While this is more secure and eliminates
> unnecessary side effects, it breaks transparent compatibility when trying to
> migrate from Docker.
> As a trade-off, we should allow host path creation in a restricted manner, by
> introducing a new Mesos agent flag ({{--host_path_volume_force_creation}}) as
> a colon-separated whitelist (similar to the format of POSIX's {{$PATH}}
> environment variable), under whose items' subdirectories the host paths are
> allowed to be created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9383) Registry puller needs to implement retry upon failing image pulls
Jason Lai created MESOS-9383:
Summary: Registry puller needs to implement retry upon failing
image pulls
Key: MESOS-9383
URL: https://issues.apache.org/jira/browse/MESOS-9383
Project: Mesos
Issue Type: Improvement
Components: containerization
Reporter: Jason Lai
UCR's {{RegistryPuller}} doesn't support [retry upon failures on fetching
container
images|https://github.com/apache/mesos/blob/1.7.0/src/slave/containerizer/mesos/provisioner/docker/registry_puller.cpp]
and below is an example of the issue:
{code:text}
mesos-slave.{hostname}.root.log.INFO.20181016-193329.90745.6.gz:E1029
21:28:16.114250 90838 slave.cpp:6191] Container
'28a416f4-9b3f-41f5-b343-17281c796c81' for executor
'747f92c4-a0d7-4b8a-927a-596feac33af1-1-4' of framework
3dcc744f-016c-6579-9b82-6325424502d2- failed to start: Collect failed:
Failed to perform 'curl': curl: (18) transfer closed with 9732 bytes remaining
to read
mesos-slave.{hostname}.root.log.INFO.20181016-193329.90745.6.gz:E1029
21:28:16.118737 90829 slave.cpp:6191] Container
'e80c5a81-c849-4aa3-bae3-a1d55fa1b9da' for executor
'747f92c4-a0d7-4b8a-927a-596feac33af1-2-4' of framework
3dcc744f-016c-6579-9b82-6325424502d2- failed to start: Collect failed:
Failed to perform 'curl': curl: (18) transfer closed with 9732 bytes remaining
to read
{code}
On the other hand, such logic was
[implemented|https://github.com/moby/moby/blob/v17.05.0-ce/distribution/xfer/download.go#L250-L304]
long time ago in Docker and quite necessary for UCR at scale.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9009) Support for creation non-existing host paths in a whitelist as source paths
[
https://issues.apache.org/jira/browse/MESOS-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678863#comment-16678863
]
Jason Lai commented on MESOS-9009:
--
Discussed in [one of the previous WG
sync|https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugtc2nHR89skFXSpU/edit?pli=1#heading=h.jhr91rmesh0a].
Patches include:
* https://reviews.apache.org/r/65811/
* https://reviews.apache.org/r/68832/
* https://reviews.apache.org/r/69286/
* https://reviews.apache.org/r/69287/
> Support for creation non-existing host paths in a whitelist as source paths
> ---
>
> Key: MESOS-9009
> URL: https://issues.apache.org/jira/browse/MESOS-9009
> Project: Mesos
> Issue Type: Task
> Components: containerization
>Affects Versions: 1.8.0
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Major
> Labels: containerizer, mount, path
>
> Docker creates a directory specified in {{docker run}}'s {{--volume}}/{{-v}}
> option as the source path that will get bind-mounted into the container, if
> the source location didn't originally exist on the host.
> Unlike Docker, UCR bails on launching containers if any of their host mount
> paths doesn't originally exist. While this is more secure and eliminates
> unnecessary side effects, it breaks transparent compatibility when trying to
> migrate from Docker.
> As a trade-off, we should allow host path creation in a restricted manner, by
> introducing a new Mesos agent flag ({{--host_path_volume_force_creation}}) as
> a colon-separated whitelist (similar to the format of POSIX's {{$PATH}}
> environment variable), under whose items' subdirectories the host paths are
> allowed to be created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9009) Support for creation non-existing host paths in a whitelist as source paths
Jason Lai created MESOS-9009:
Summary: Support for creation non-existing host paths in a
whitelist as source paths
Key: MESOS-9009
URL: https://issues.apache.org/jira/browse/MESOS-9009
Project: Mesos
Issue Type: Task
Components: containerization
Reporter: Jason Lai
Assignee: Jason Lai
Docker creates a directory specified in {{docker run}}'s {{--volume}}/{{-v}}
option as the source path that will get bind-mounted into the container, if the
source location didn't originally exist on the host.
Unlike Docker, UCR bails on launching containers if any of their host mount
paths doesn't originally exist. While this is more secure and eliminates
unnecessary side effects, it breaks transparent compatibility when trying to
migrate from Docker.
As a trade-off, we should allow host path creation in a restricted manner, by
introducing a new Mesos agent flag ({{--host_path_volume_force_creation}}) as a
colon-separated whitelist (similar to the format of POSIX's {{$PATH}}
environment variable), under whose items' subdirectories the host paths are
allowed to be created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-8948) Mesos Container should support changing the size of /dev/shm
[ https://issues.apache.org/jira/browse/MESOS-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lai reassigned MESOS-8948: Assignee: Jason Lai > Mesos Container should support changing the size of /dev/shm > > > Key: MESOS-8948 > URL: https://issues.apache.org/jira/browse/MESOS-8948 > Project: Mesos > Issue Type: Improvement > Components: agent, containerization >Reporter: chenmingjie >Assignee: Jason Lai >Priority: Minor > Labels: containerizer > > Some program like pytorch use large amount of /dev/shm to create share memory, > Docker Support --shm-size flag to change the size of /dev/shm, but mesos > container does not. > Mesos container should support the changing of the size of /dev/shm -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-6798) Volumes in `/dev/shm` overridden by mesos containerizer
[
https://issues.apache.org/jira/browse/MESOS-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478378#comment-16478378
]
Jason Lai commented on MESOS-6798:
--
https://reviews.apache.org/r/67177 is the patch for this task. It depends on
the patches for [MESOS-8257|https://issues.apache.org/jira/browse/MESOS-8257]
> Volumes in `/dev/shm` overridden by mesos containerizer
> ---
>
> Key: MESOS-6798
> URL: https://issues.apache.org/jira/browse/MESOS-6798
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.1.1, 1.2.0, 1.3.1, 1.4.1, 1.5.0
>Reporter: Zhongbo Tian
>Assignee: Jason Lai
>Priority: Major
>
> When making a volume into `/dev/shm`, the volume is overridden by default
> mount point.
> For example:
> {code}
> mesos-execute --master=mesos-master --name=test --docker_image=busybox
> --volumes='[{"container_path":"/tmp/hosts", "host_path":"/etc/hosts",
> "mode":"RO"}]' --command="cat /tmp/hosts"
> {code}
> This will get an error for "No such file or directory"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8257) Unified Containerizer "leaks" a target container mount path to the host FS when the target resolves to an absolute path
[
https://issues.apache.org/jira/browse/MESOS-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478377#comment-16478377
]
Jason Lai commented on MESOS-8257:
--
After discussions with [~jieyu] on the refactoring done in {{launch.cpp}} for
platform-specific support, I decided to drop some of the patches till we reach
an consensus on how refactoring should be done for {{launch.cpp}}.
The new patch chain for this particular task has become:
* https://reviews.apache.org/r/65811
* https://reviews.apache.org/r/65812
* https://reviews.apache.org/r/65900
* https://reviews.apache.org/r/67175
* https://reviews.apache.org/r/67176
I'll add more patches for tests soon.
> Unified Containerizer "leaks" a target container mount path to the host FS
> when the target resolves to an absolute path
> ---
>
> Key: MESOS-8257
> URL: https://issues.apache.org/jira/browse/MESOS-8257
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.1, 1.4.1, 1.5.0
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Critical
> Labels: bug, containerizer, mountpath
>
> If a target path under the root FS provisioned from an image resolves to an
> absolute path, it will not appear in the container root FS after
> {{pivot_root(2)}} is called.
> A typical example is that when the target path is under {{/var/run}} (e.g.
> {{/var/run/some-dir}}), which is usually a symlink to an absolute path of
> {{/run}} in Debian images, the target path will get resolved as and created
> at {{/run/some-dir}} in the host root FS, after the container root FS gets
> provisioned. The target path will get unmounted after {{pivot_root(2)}} as it
> is part of the old root (host FS).
> A workaround is to use {{/run}} instead of {{/var/run}}, but absolute
> symlinks need to be resolved within the scope of the container root FS path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8257) Unified Containerizer "leaks" a target container mount path to the host FS when the target resolves to an absolute path
[
https://issues.apache.org/jira/browse/MESOS-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454867#comment-16454867
]
Jason Lai commented on MESOS-8257:
--
[~alexr]: so far we have the following patches in review:
* https://reviews.apache.org/r/65811/
* https://reviews.apache.org/r/65812/
* https://reviews.apache.org/r/65898/
* https://reviews.apache.org/r/65899/
* https://reviews.apache.org/r/65900/
I'll have more patches coming up soon
> Unified Containerizer "leaks" a target container mount path to the host FS
> when the target resolves to an absolute path
> ---
>
> Key: MESOS-8257
> URL: https://issues.apache.org/jira/browse/MESOS-8257
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Affects Versions: 1.3.1, 1.4.1, 1.5.0
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Critical
> Labels: bug, containerizer, mountpath
>
> If a target path under the root FS provisioned from an image resolves to an
> absolute path, it will not appear in the container root FS after
> {{pivot_root(2)}} is called.
> A typical example is that when the target path is under {{/var/run}} (e.g.
> {{/var/run/some-dir}}), which is usually a symlink to an absolute path of
> {{/run}} in Debian images, the target path will get resolved as and created
> at {{/run/some-dir}} in the host root FS, after the container root FS gets
> provisioned. The target path will get unmounted after {{pivot_root(2)}} as it
> is part of the old root (host FS).
> A workaround is to use {{/run}} instead of {{/var/run}}, but absolute
> symlinks need to be resolved within the scope of the container root FS path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8651) Potential memory leaks in the `volume/sandbox_path` isolator
[
https://issues.apache.org/jira/browse/MESOS-8651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16401204#comment-16401204
]
Jason Lai commented on MESOS-8651:
--
[~gilbert]: We have a patch available at https://reviews.apache.org/r/66104/.
Thanks for the code review!
cc [~zhitao], [~jieyu]
> Potential memory leaks in the `volume/sandbox_path` isolator
>
>
> Key: MESOS-8651
> URL: https://issues.apache.org/jira/browse/MESOS-8651
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Major
> Labels: easyfix, patch
>
> The {{sandboxes}} hashmap object of
> {{mesos::internal::slave::VolumeSandboxPathIsolatorProcess}} bears the risk
> of potential memory leak.
> It [adds the sandbox path upon each container
> launch|https://github.com/apache/mesos/blob/1.5.x/src/slave/containerizer/mesos/isolators/volume/sandbox_path.cpp#L119-L122]
> and does not remove the sandbox path after cleaning up the container. As the
> life cycle of an isolator is attached to that of {{MesosContainerizer}}, this
> means that more and more sandbox paths will get added to the {{sandboxes}}
> hashmap object, as Mesos containers keep being launched and will likely blow
> up Mesos agent eventually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8654) The `/proc/sys` mount point in Mesos containers should also include `nosuid,noexec,nodev` mount options.
[
https://issues.apache.org/jira/browse/MESOS-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396475#comment-16396475
]
Jason Lai commented on MESOS-8654:
--
[~jieyu], [~gilbert], [~idownes] The patch for this issue is now available at
[RB #66034|https://reviews.apache.org/r/66034/]. cc [~zhitao] & [~cinchurge]
> The `/proc/sys` mount point in Mesos containers should also include
> `nosuid,noexec,nodev` mount options.
>
>
> Key: MESOS-8654
> URL: https://issues.apache.org/jira/browse/MESOS-8654
> Project: Mesos
> Issue Type: Bug
> Components: containerization, security
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Critical
> Labels: easyfix, patch, security
>
> After {{/proc/sys}} gets remounted as read-only in a Mesos container, its
> mount options becomes {{ro,relatime}} only. It needs to share other mount
> options of {{/proc}}, including {{nosuid,noexec,nodev}} for security reasons.
> Additional questions: shall we also sandbox other important system mount
> points, like Systemd does with
> [{{ProtectSystem=}}|https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=]
> (or at least
> [{{ProtectKernelTunables=}}|https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables=])
> and Docker does with {{docker run}} without {{--privileged}}?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8654) The `/proc/sys` mount point in Mesos containers should also include `nosuid,noexec,nodev` mount options.
[
https://issues.apache.org/jira/browse/MESOS-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392339#comment-16392339
]
Jason Lai commented on MESOS-8654:
--
Oh I forgot to mention, also it is absolutely necessary to remount
{{/proc/sysrq-trigger}} as read-only. Otherwise users can [perform malicious
operations|https://en.wikipedia.org/wiki/Magic_SysRq_key] like rebooting the
host.
> The `/proc/sys` mount point in Mesos containers should also include
> `nosuid,noexec,nodev` mount options.
>
>
> Key: MESOS-8654
> URL: https://issues.apache.org/jira/browse/MESOS-8654
> Project: Mesos
> Issue Type: Bug
> Components: containerization, security
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Minor
> Labels: easyfix, patch, security
>
> After {{/proc/sys}} gets remounted as read-only in a Mesos container, its
> mount options becomes {{ro,relatime}} only. It needs to share other mount
> options of {{/proc}}, including {{nosuid,noexec,nodev}} for security reasons.
> Additional questions: shall we also sandbox other important system mount
> points, like Systemd does with
> [{{ProtectSystem=}}|https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=]
> (or at least
> [{{ProtectKernelTunables=}}|https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables=])
> and Docker does with {{docker run}} without {{--privileged}}?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-8654) The `/proc/sys` mount point in Mesos containers should also include `nosuid,noexec,nodev` mount options.
Jason Lai created MESOS-8654:
Summary: The `/proc/sys` mount point in Mesos containers should
also include `nosuid,noexec,nodev` mount options.
Key: MESOS-8654
URL: https://issues.apache.org/jira/browse/MESOS-8654
Project: Mesos
Issue Type: Bug
Components: containerization, security
Reporter: Jason Lai
Assignee: Jason Lai
After {{/proc/sys}} gets remounted as read-only in a Mesos container, its mount
options becomes {{ro,relatime}} only. It needs to share other mount options of
{{/proc}}, including {{nosuid,noexec,nodev}} for security reasons.
Additional questions: shall we also sandbox other important system mount
points, like Systemd does with
[{{ProtectSystem=}}|https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=]
(or at least
[{{ProtectKernelTunables=}}|https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables=])
and Docker does with {{docker run}} without {{--privileged}}?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-8651) Potential memory leaks in the `volume/sandbox_path` isolator
[
https://issues.apache.org/jira/browse/MESOS-8651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16392273#comment-16392273
]
Jason Lai commented on MESOS-8651:
--
Patching for this bug should be fairly easy. [~jieyu], [~gilbert], i think we
can release this fairly quickly once we have patch(es) ready?
> Potential memory leaks in the `volume/sandbox_path` isolator
>
>
> Key: MESOS-8651
> URL: https://issues.apache.org/jira/browse/MESOS-8651
> Project: Mesos
> Issue Type: Bug
> Components: containerization
>Reporter: Jason Lai
>Assignee: Jason Lai
>Priority: Major
> Labels: easyfix, patch
>
> The {{sandboxes}} hashmap object of
> {{mesos::internal::slave::VolumeSandboxPathIsolatorProcess}} bears the risk
> of potential memory leak.
> It [adds the sandbox path upon each container
> launch|https://github.com/apache/mesos/blob/1.5.x/src/slave/containerizer/mesos/isolators/volume/sandbox_path.cpp#L119-L122]
> and does not remove the sandbox path after cleaning up the container. As the
> life cycle of an isolator is attached to that of {{MesosContainerizer}}, this
> means that more and more sandbox paths will get added to the {{sandboxes}}
> hashmap object, as Mesos containers keep being launched and will likely blow
> up Mesos agent eventually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-8327) Add container-specific CGroup FS mounts under /sys/fs/cgroup/* to Mesos containers
Jason Lai created MESOS-8327:
Summary: Add container-specific CGroup FS mounts under
/sys/fs/cgroup/* to Mesos containers
Key: MESOS-8327
URL: https://issues.apache.org/jira/browse/MESOS-8327
Project: Mesos
Issue Type: Task
Components: containerization
Reporter: Jason Lai
Assignee: Jason Lai
Containers launched with Unified Containerizer do not include
container-specific CGroup FS mounts under {{/sys/fs/cgroup}}, which are created
by default by Docker (usually readonly for unprivileged containers). Let's
honor the same convention for Mesos containers.
For example, this is needed by Uber's
[{{automaxprocs}}|https://github.com/uber-go/automaxprocs] patch for Go
programs, which amends {{GOMAXPROCS}} per CPU quota and requires access to the
CPU cgroup subsystem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-8257) Unified Containerizer "leaks" a target container mount path to the host FS when the target resolves to an absolute path
Jason Lai created MESOS-8257:
Summary: Unified Containerizer "leaks" a target container mount
path to the host FS when the target resolves to an absolute path
Key: MESOS-8257
URL: https://issues.apache.org/jira/browse/MESOS-8257
Project: Mesos
Issue Type: Bug
Components: containerization
Reporter: Jason Lai
Assignee: Jason Lai
If a target path under the root FS provisioned from an image resolves to an
absolute path, it will not appear in the container root FS after
{{pivot_root(2)}} is called.
A typical example is that when the target path is under {{/var/run}} (e.g.
{{/var/run/some-dir}}), which is usually a symlink to an absolute path of
{{/run}} in Debian images, the target path will get resolved as and created at
{{/run/some-dir}} in the host root FS, after the container root FS gets
provisioned. The target path will get unmounted after {{pivot_root(2)}} as it
is part of the old root (host FS).
A workaround is to use {{/run}} instead of {{/var/run}}, but absolute symlinks
need to be resolved within the scope of the container root FS path.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MESOS-7843) Support blkio control in cgroups blkio subsystem.
[ https://issues.apache.org/jira/browse/MESOS-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202853#comment-16202853 ] Jason Lai edited comment on MESOS-7843 at 10/13/17 12:17 AM: - Oops, scratch the previous message. I meant to comment in MESOS-8041 instead was (Author: jasonlai): I'll add descriptions about potential performance implications for enabling this isolator. > Support blkio control in cgroups blkio subsystem. > - > > Key: MESOS-7843 > URL: https://issues.apache.org/jira/browse/MESOS-7843 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: Gilbert Song >Priority: Minor > Labels: mesosphere > > Now we support blkio statistics in cgroup blkio subsystem, which read the > blkio stats files in cgroups and exposed them in resource statistics. We may > want to support blkio control functionalities in BlkioSubsystem::prepare(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-8041) Add a document for `cgroups/blkio` isolation
[
https://issues.apache.org/jira/browse/MESOS-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Lai reassigned MESOS-8041:
Assignee: Jason Lai
> Add a document for `cgroups/blkio` isolation
>
>
> Key: MESOS-8041
> URL: https://issues.apache.org/jira/browse/MESOS-8041
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Qian Zhang
>Assignee: Jason Lai
>
> Now we have supported {{cgroups/blkio}} isolation in Mesos agent for
> collecting blkio statistics, we need to add a document for it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MESOS-7843) Support blkio control in cgroups blkio subsystem.
[ https://issues.apache.org/jira/browse/MESOS-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lai reassigned MESOS-7843: Assignee: (was: Jason Lai) > Support blkio control in cgroups blkio subsystem. > - > > Key: MESOS-7843 > URL: https://issues.apache.org/jira/browse/MESOS-7843 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: Gilbert Song >Priority: Minor > Labels: mesosphere > > Now we support blkio statistics in cgroup blkio subsystem, which read the > blkio stats files in cgroups and exposed them in resource statistics. We may > want to support blkio control functionalities in BlkioSubsystem::prepare(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-8041) Add a document for `cgroups/blkio` isolation
[
https://issues.apache.org/jira/browse/MESOS-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202855#comment-16202855
]
Jason Lai commented on MESOS-8041:
--
Initial doc for review: https://reviews.apache.org/r/62961/ I'll add
descriptions about potential performance implications for enabling this
isolator.
> Add a document for `cgroups/blkio` isolation
>
>
> Key: MESOS-8041
> URL: https://issues.apache.org/jira/browse/MESOS-8041
> Project: Mesos
> Issue Type: Documentation
> Components: documentation
>Reporter: Qian Zhang
>Assignee: Jason Lai
>
> Now we have supported {{cgroups/blkio}} isolation in Mesos agent for
> collecting blkio statistics, we need to add a document for it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (MESOS-7843) Support blkio control in cgroups blkio subsystem.
[ https://issues.apache.org/jira/browse/MESOS-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lai updated MESOS-7843: - Comment: was deleted (was: Initial doc for review: https://reviews.apache.org/r/62961/) > Support blkio control in cgroups blkio subsystem. > - > > Key: MESOS-7843 > URL: https://issues.apache.org/jira/browse/MESOS-7843 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: Gilbert Song >Priority: Minor > Labels: mesosphere > > Now we support blkio statistics in cgroup blkio subsystem, which read the > blkio stats files in cgroups and exposed them in resource statistics. We may > want to support blkio control functionalities in BlkioSubsystem::prepare(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7843) Support blkio control in cgroups blkio subsystem.
[ https://issues.apache.org/jira/browse/MESOS-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202853#comment-16202853 ] Jason Lai commented on MESOS-7843: -- I'll add descriptions about potential performance implications for enabling this isolator. > Support blkio control in cgroups blkio subsystem. > - > > Key: MESOS-7843 > URL: https://issues.apache.org/jira/browse/MESOS-7843 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: Gilbert Song >Assignee: Jason Lai >Priority: Minor > Labels: mesosphere > > Now we support blkio statistics in cgroup blkio subsystem, which read the > blkio stats files in cgroups and exposed them in resource statistics. We may > want to support blkio control functionalities in BlkioSubsystem::prepare(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MESOS-7843) Support blkio control in cgroups blkio subsystem.
[ https://issues.apache.org/jira/browse/MESOS-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lai reassigned MESOS-7843: Assignee: Jason Lai > Support blkio control in cgroups blkio subsystem. > - > > Key: MESOS-7843 > URL: https://issues.apache.org/jira/browse/MESOS-7843 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: Gilbert Song >Assignee: Jason Lai >Priority: Minor > Labels: mesosphere > > Now we support blkio statistics in cgroup blkio subsystem, which read the > blkio stats files in cgroups and exposed them in resource statistics. We may > want to support blkio control functionalities in BlkioSubsystem::prepare(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7843) Support blkio control in cgroups blkio subsystem.
[ https://issues.apache.org/jira/browse/MESOS-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202850#comment-16202850 ] Jason Lai commented on MESOS-7843: -- Initial doc for review: https://reviews.apache.org/r/62961/ > Support blkio control in cgroups blkio subsystem. > - > > Key: MESOS-7843 > URL: https://issues.apache.org/jira/browse/MESOS-7843 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: Gilbert Song >Priority: Minor > Labels: mesosphere > > Now we support blkio statistics in cgroup blkio subsystem, which read the > blkio stats files in cgroups and exposed them in resource statistics. We may > want to support blkio control functionalities in BlkioSubsystem::prepare(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7990) Support systemd named hierarchy (name=systemd) for Mesos Containerizer.
[
https://issues.apache.org/jira/browse/MESOS-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175448#comment-16175448
]
Jason Lai commented on MESOS-7990:
--
I'm all for the systemd support. But it doesn't go that easily as
{{/systemd/mesos/}}, as Systemd has imposed some conventions on tasks'
cgroup names. There are some references
[here|https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/sec-default_cgroup_hierarchies].
AFAIK, rkt has aligned pretty well with the systemd conventions for their
containers. Would be worth looking at what they're doing
> Support systemd named hierarchy (name=systemd) for Mesos Containerizer.
> ---
>
> Key: MESOS-7990
> URL: https://issues.apache.org/jira/browse/MESOS-7990
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Reporter: Jie Yu
>
> Similar to docker's cgroupfs cgroup driver, we should create cgroups under
> /sys/fs/cgroup/systemd (if it exists), and move container pid into the
> corresponding cgroup ( /sys/fs/cgroup/systemd/mesos/).
> This can give us a bunch of benefits:
> 1) systemd-cgls can list mesos containers
> 2) systemd-cgtop can show stats for mesos containers
> ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-6162) Add support for cgroups blkio subsystem blkio statistics.
[ https://issues.apache.org/jira/browse/MESOS-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108168#comment-16108168 ] Jason Lai commented on MESOS-6162: -- Thanks a lot for shepherding my changes while I was away for vacation, [~gilbert]! And no worries! Glad to get my code committed to upstream, regardless of the committer name. We still have a lot of tasks to collaborate upon onwards :) > Add support for cgroups blkio subsystem blkio statistics. > - > > Key: MESOS-6162 > URL: https://issues.apache.org/jira/browse/MESOS-6162 > Project: Mesos > Issue Type: Task > Components: cgroups, containerization >Reporter: haosdent >Assignee: Jason Lai > Labels: cgroups, containerizer, mesosphere > Fix For: 1.4.0 > > > Noted that cgroups blkio subsystem may have performance issue, refer to > https://github.com/opencontainers/runc/issues/861 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-6162) Add support for cgroups blkio subsystem
[ https://issues.apache.org/jira/browse/MESOS-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16045210#comment-16045210 ] Jason Lai commented on MESOS-6162: -- I had a long time diff that I didn't get to submit yet. Now rebased to the master and squashed into one commit at: https://reviews.apache.org/r/59960/ [~gilbert] [~jieyu] > Add support for cgroups blkio subsystem > --- > > Key: MESOS-6162 > URL: https://issues.apache.org/jira/browse/MESOS-6162 > Project: Mesos > Issue Type: Task >Reporter: haosdent >Assignee: Jason Lai > > Noted that cgroups blkio subsystem may have performance issue, refer to > https://github.com/opencontainers/runc/issues/861 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-6162) Add support for cgroups blkio subsystem
[ https://issues.apache.org/jira/browse/MESOS-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044040#comment-16044040 ] Jason Lai commented on MESOS-6162: -- [~haoyixin] Hi! We didn't get to prioritize this as the diff was pending for review. But we'll resurrect this task, for the sake of incoming demands on this. Will keep you updated as we progress > Add support for cgroups blkio subsystem > --- > > Key: MESOS-6162 > URL: https://issues.apache.org/jira/browse/MESOS-6162 > Project: Mesos > Issue Type: Task >Reporter: haosdent >Assignee: Jason Lai > > Noted that cgroups blkio subsystem may have performance issue, refer to > https://github.com/opencontainers/runc/issues/861 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MESOS-7141) Support hook scripts to customize actions for container's lifecycle
[ https://issues.apache.org/jira/browse/MESOS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lai updated MESOS-7141: - Summary: Support hook scripts to customize actions for container's lifecycle (was: https://uber.zoom.us/j/153272109) > Support hook scripts to customize actions for container's lifecycle > --- > > Key: MESOS-7141 > URL: https://issues.apache.org/jira/browse/MESOS-7141 > Project: Mesos > Issue Type: Task > Components: containerization, isolation >Reporter: Jason Lai >Assignee: Jason Lai > > Inspired by [hooks | > https://github.com/opencontainers/runtime-spec/blob/master/config.md#hooks] > in [OCI's runtime spec | https://github.com/opencontainers/runtime-spec], it > would be great to have scripts hooked into the lifecycle of containers. > The OCI doc has specified 3 stages for hooking: > * Prestart > * Poststart > * Poststop > We can consider having the 3 stages to start with. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MESOS-7141) https://uber.zoom.us/j/153272109
Jason Lai created MESOS-7141: Summary: https://uber.zoom.us/j/153272109 Key: MESOS-7141 URL: https://issues.apache.org/jira/browse/MESOS-7141 Project: Mesos Issue Type: Task Components: containerization, isolation Reporter: Jason Lai Assignee: Jason Lai Inspired by [hooks | https://github.com/opencontainers/runtime-spec/blob/master/config.md#hooks] in [OCI's runtime spec | https://github.com/opencontainers/runtime-spec], it would be great to have scripts hooked into the lifecycle of containers. The OCI doc has specified 3 stages for hooking: * Prestart * Poststart * Poststop We can consider having the 3 stages to start with. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MESOS-6797) Split src/linux/cgroups.{hpp,cpp} into smaller units under src/linux/cgroups/*.{hpp,cpp}
Jason Lai created MESOS-6797:
Summary: Split src/linux/cgroups.{hpp,cpp} into smaller units
under src/linux/cgroups/*.{hpp,cpp}
Key: MESOS-6797
URL: https://issues.apache.org/jira/browse/MESOS-6797
Project: Mesos
Issue Type: Improvement
Components: cgroups
Reporter: Jason Lai
Assignee: Jason Lai
Priority: Minor
Like what we have done in MESOS-4697, {{src/linux/cgroups.hpp}} and
{{src/linux/cgroups.cpp}} have grown to a point where they have become a bit
hard to maintain.
This task is created to track our effort of refactoring the 2 files into units
under {{src/linux/cgroups}} around respective subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6162) Add support for cgroups blkio subsystem
[ https://issues.apache.org/jira/browse/MESOS-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15651768#comment-15651768 ] Jason Lai commented on MESOS-6162: -- Thanks Haosdent! I also asked to Zhitao to temporarily hold this task for me before I can assign it to myself. > Add support for cgroups blkio subsystem > --- > > Key: MESOS-6162 > URL: https://issues.apache.org/jira/browse/MESOS-6162 > Project: Mesos > Issue Type: Task >Reporter: haosdent >Assignee: Zhitao Li > > Noted that cgroups blkio subsystem may have performance issue, refer to > https://github.com/opencontainers/runc/issues/861 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6541) Mesos test should mount cgroups_root
[
https://issues.apache.org/jira/browse/MESOS-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15634334#comment-15634334
]
Jason Lai commented on MESOS-6541:
--
It would be good to call `unshare(2)` with `CLONE_NEWNS` to fork a new mount
namespace for the test suite process. In this case, you can do whatever you
want with the process' mount table without affecting other processes' view of
their root FS.
However, during the test runs, it is important to make sure that minimum
changes are made to cgroup hierarchies or the changes should be idempotent,
since such changes do have side effects across mount namespaces.
> Mesos test should mount cgroups_root
>
>
> Key: MESOS-6541
> URL: https://issues.apache.org/jira/browse/MESOS-6541
> Project: Mesos
> Issue Type: Bug
> Components: cgroups, test
>Reporter: Yan Xu
>
> Currently on hosts without prior cgroups setup and sysfs is mounted at /sys,
> mesos tests would fail like this:
> {noformat:title=}
> [ RUN ] HTTPCommandExecutorTest.TerminateWithACK
> F1103 19:54:40.807538 439804 command_executor_tests.cpp:236]
> CHECK_SOME(_containerizer): Failed to create launcher: Failed to create Linux
> launcher: Failed to mount cgroups hierarchy at '/sys/fs/cgroup/fr
> eezer': Failed to create directory '/sys/fs/cgroup/freezer': No such file or
> directory
> {noformat}
> This is because the agent chooses to use {{LinuxLauncher}} based on
> availability of the {{freezer}} subsystem alone. However for it to work, one
> needs to do the following
> {noformat:title=}
> mount -t tmpfs cgroup_root /sys/fs/cgroup
> {noformat}
> in order to make {{/sys/fs/cgroup}} writable.
> I have always run the command manually in the past when this failure happens
> but this could be baffling especially to new developers. Mesos tests should
> just mount it if it's not already done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6503) Mesos containerizer launch should not be pid 1 inside the container.
[ https://issues.apache.org/jira/browse/MESOS-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616529#comment-15616529 ] Jason Lai commented on MESOS-6503: -- Would be good to: # make the `mesos-containerizer`'s launcher process live outside of the PID namespace like Docker containerd's shim process; # the namespace unsharing should happen in the launcher's child process before `execv*(2)` into executors > Mesos containerizer launch should not be pid 1 inside the container. > > > Key: MESOS-6503 > URL: https://issues.apache.org/jira/browse/MESOS-6503 > Project: Mesos > Issue Type: Improvement >Reporter: Jie Yu > > This can solve two issues: > 1) people cannot see arguments of mesos-containerizer launch > 2) allow users to use other init system (e.g., systemd) inside the container -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6162) Add support for cgroups blkio subsystem
[ https://issues.apache.org/jira/browse/MESOS-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15616497#comment-15616497 ] Jason Lai commented on MESOS-6162: -- Hi haosdent! Not sure if you're working on this ticket, at Uber we have been collecting blkio stats for Docker containers, and I would like to take this task as an effort to maintain feature parity with our Docker containers. Are you okay with that? > Add support for cgroups blkio subsystem > --- > > Key: MESOS-6162 > URL: https://issues.apache.org/jira/browse/MESOS-6162 > Project: Mesos > Issue Type: Task >Reporter: haosdent > > Noted that cgroups blkio subsystem may have performance issue, refer to > https://github.com/opencontainers/runc/issues/861 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
