[
https://issues.apache.org/jira/browse/YARN-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16630787#comment-16630787
]
Eric Yang edited comment on YARN-6456 at 9/27/18 5:38 PM:
----------------------------------------------------------
[~ccondit-target] Thank you for the explanation. In YARN service, user does
not require to specify the runtime, and it will run the
DefaultLinuxContainerRuntime because it is the default. I understand more
clearly that this JIRA is to focus on setting a default other than
DefaultLinuxContainerRuntime, when user does not specify the default. User who
is using YARN service LLAP application which did not specify the default, and
system administrator override the default. It might break existing users
because the behavior has changed. The responsibility of the compatibility
breakage depends on the system administrator rather than code change. Hence,
this change is backward compatible by default, and give system admin more
control to steer the developer to work with specific runtime. The
documentation can explain this more clearly by showing
yarn.nodemanager.runtime.linux.type and
yarn.nodemanager.runtime.linux.allowed-runtimes side by side for clarity, or
find this JIRA for the explanation. I think the patch is ready.
was (Author: eyang):
[~ccondit-target] Thank you for the explanation. In YARN service, user does
not require to specify the runtime, and it will run the
DefaultLinuxContainerRuntime because it is the default. I understand more
clearly that this JIRA is to focus on setting a default other than
DefaultLinuxContainerRuntime, when user does not specify the default. User who
is using YARN service LLAP application which did not specify the default, and
system administrator override the default. It might break existing users
because the behavior has changed. The responsibility of the compatibility
breakage depends on the system administrator rather than code change. Hence,
this change is backward compatible by default, and give system admin more
control to steer the developer to work with specific runtime. The
documentation can explain this more clearly by showing
yarn.nodemanager.runtime.linux.type and
yarn.nodemanager.runtime.linux.allowed-runtimes side by side for clarity, or
find this JIRA for the explaination. I think the patch is ready.
> Allow administrators to set a single ContainerRuntime for all containers
> ------------------------------------------------------------------------
>
> Key: YARN-6456
> URL: https://issues.apache.org/jira/browse/YARN-6456
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: nodemanager
> Reporter: Miklos Szegedi
> Assignee: Craig Condit
> Priority: Major
> Labels: Docker
> Attachments: YARN-6456-ForceDockerRuntimeIfSupported.patch,
> YARN-6456.001.patch, YARN-6456.002.patch, YARN-6456.003.patch,
> YARN-6456.004.patch, YARN-6456.005.patch
>
>
>
> With LCE, there are multiple ContainerRuntimes available for handling
> different types of containers; default, docker, java sandbox. Admins should
> have the ability to override the user decision and set a single global
> ContainerRuntime to be used for all containers.
> Original Description:
> {quote}One reason to use Docker containers is to be able to isolate different
> workloads, even, if they run as the same user.
> I have noticed some issues in the current design:
> 1. DockerLinuxContainerRuntime mounts containerLocalDirs
> {{nm-local-dir/usercache/user/appcache/application_1491598755372_0011/}} and
> userLocalDirs {{nm-local-dir/usercache/user/}}, so that a container can see
> and modify the files of another container. I think the application file cache
> directory should be enough for the container to run in most of the cases.
> 2. The whole cgroups directory is mounted. Would the container directory be
> enough?
> 3. There is no way to enforce exclusive use of Docker for all containers.
> There should be an option that it is not the user but the admin that requires
> to use Docker.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
