[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420991#comment-16420991
]
Eric Yang commented on YARN-7654:
---------------------------------
[~jlowe]
{quote}
Why would be be specifying both arguments? All of the environment variables
would go into the envfile.
{quote}
It might be preferable to have user defined variables in envfile, and system
specific environment variables goes into "-e" to prevent override. We need to
converge on possible solutions with least amount of loopholes. How about make
both solutions available to user? User can specify either env-file= in cmd
file, or use [docker-command-environment] to define -e environment variables.
The env-file will trigger localization of hdfs env file to localized directory
and pass along with --env-file. If user specify the environment key/value pair
in yarnfile, then we construct them as -e parameters? This will allow both
preference to work, also eliminate the loophole that key/value pair
materialized file conflicting with user specified configuration file.
{quote}
The file would go into the nmPrivate directory which is not accessible by the
user, only writable by the NM user and would be read by the container-executor.
This is the same location where the NM writes the launch script and tokens
today to be picked up by the container-executor. The user would not be able to
access or overwrite this file.
{quote}
This is only partially true, launcher script is copied to appcache directory
because the copy in nmPrivate is partially complete, and doesn't have
executable permission and file ownership. If envfile is in nmPrivate only, it
become non-viewable, and need to copy to log directory for debugging purpose.
Most users are likely to prefer to see -e on stdout.txt because it is one click
less, and provide clear view of the launch command. However, I agree there are
also merits in using ENV file in case passwords are being passed via ENV. For
containing the scope of this JIRA, I think making the easy case work has higher
priority. I file YARN-8097 as enhancement for env-file support.
> 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
> Attachments: YARN-7654.001.patch, YARN-7654.002.patch,
> YARN-7654.003.patch, YARN-7654.004.patch, YARN-7654.005.patch,
> YARN-7654.006.patch, YARN-7654.007.patch
>
>
> 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}
> h3. Use ENTRY_POINT
> {code}
> docker run [image]:[version]
> {code}
--
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
