Eric Badger commented on YARN-7654:

bq. The parent layer (container-executor) provide the same information to the 
first process in docker. The observed behavior is caused by how the docker 
image was originally constructed, not caused by different code path leading to 
the difference in behavior.
That's not true. In the current implementation the environment is being written 
out into launch_container.sh (and in a special way such as to only overwrite 
variables with user-defined variables, not NM-defined), which gets executed 
*after* the docker environment variables are set. By adding the variables via 
{{-e K=V}}, we are switching around the order and losing the ability to 
differentiate between NM-defined and user-defined. 

I think the best approach here is to explicitly deny NM variables from being 
passed on the command line when ENTRY_POINT is being used. I don't see a case 
where a container using ENTRY_POINT is going to need NM variables, since the 
container should be self-contained. We're already making assumptions about 
bind-mounts and such. This would require a follow-up change to YARN-7677, 

> 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