Shane Kumpf commented on YARN-7654:

{quote}The second mode will launch container and bind-mount HDFS via NFS 
gateway for non-Hadoop workload.{quote}
I'd say there is a third mode of operation then. Don't set the workdir at all 
and let it be part of the container's root filesystem. Docker will have no 
problem cleaning up those files and this is in line with minimizing surprises 
of running an existing Docker container on YARN.

{quote}I plan to retain the current behavior. If USE_ENTRY_POINT is enabled, 
then it follows the second method for environment construction, and user 
defined environment variable may override image supplied environment. This 
depends on how the image is arranged.{quote}
One quick note on this, there is already an environment variable for disabling 
the launch script, let's consider reusing or removing it vs just adding yet 
another variable to set. :) See 

> Support ENTRY_POINT for docker container
> ----------------------------------------
>                 Key: YARN-7654
>                 URL: https://issues.apache.org/jira/browse/YARN-7654
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>    Affects Versions: 3.1.0
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>            Priority: Blocker
> Docker image may have ENTRY_POINT predefined, but this is not supported in 
> the current implementation.  It would be nice if we can detect existence of 
> {{launch_command}} and base on this variable launch docker container in 
> different ways:
> h3. Launch command exists
> {code}
> docker run [image]:[version]
> docker exec [container_id] [launch_command]
> {code}
> {code}
> docker run [image]:[version]
> {code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to