[ 
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443305#comment-16443305
 ] 

Eric Yang commented on YARN-7654:
---------------------------------

For following up on today's meet up discussion:

Proposal 1: Environment variables are passed as a section in .cmd file, and 
docker run construct command line arguments to pass environment variables to 
docker.  In YARN-8079, user can reference to localized env-file from HDFS to 
support complex use-case where the software developer supplied default 
environment variables, and allow system administrator to override them.

Proposal 2: All environment key/value pair are written to a file in nmPrivate 
directory, and docker run reference to filename in nmPrivate directory.  For 
debug purpose, the same file in nmPrivate directory is copied to log directory 
for debugging purpose.

The current implementation is written to support proposal 1.

Proposal 1
| Pro | Cons |
| No additional file to clean up, environment variables can be seen from docker 
run command line | docker run command is a long line of string in stdout.txt, 
it may appear ugly to some users |
| Separation of duty, allow system administrator to run services and override 
developer supplied environment variables | |
| Can hide environment secrets from stdout.txt log file (YARN-8079) | 
Environment file is not copied to log directory |
| No filename clashes in localizer directory because user define the env-file 
filename | Possible abuse of sourcing other container's environment file by 
guessing exact file path.  (high degree of difficulty) |
| Save 1 inode for not duplicating env-file in log directory, if log 
aggregation is not enabled | |
| Extensible to support "docker run" to be launched as non-yarn user.  
yarn.nodemanager.linux-container-executor.nonsecure-mode.local-user can be 
supported | |

Proposal 2
| Pro | Cons |
| Fewer code path to maintain | |
| | No separation of duty, only one way to define environment variables. |
| Hide environment secrets from stdout.txt log file | Environment file is 
copied to log directory, therefore environment secrets is still visible to yarn 
|
| | Possible limitation when docker run user != YARN user, nmPrivate directory 
is limited to yarn user. |
| | Referenced env-file is different path from what is displayed to user. It 
can be confusing to first time users. |
| | Pay 1 extra inode to duplicate env-file to log directory for debugging 
purpose. |

[~jlowe] [~ebadger] [~Jim_Brennan] [~shaneku...@gmail.com] [~billie.rinaldi] I 
try to summarize the pro and cons of both possible implementations.  I think I 
could be bias toward proposal 1 because it is already implemented.  We can 
refine code to proposal 2 if we are willing to risk the limitation that docker 
run user  == root user, and root user always have access to nmPrivate 
directory.  I am not ready to make that commitment, this is the reason that I 
ask everyone to provide their input and we respect the majority rules on this 
matter.  Thank you for reviewing this patch.

> 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, YARN-7654.008.patch, 
> YARN-7654.009.patch, YARN-7654.010.patch, YARN-7654.011.patch, 
> YARN-7654.012.patch, YARN-7654.013.patch, YARN-7654.014.patch, 
> YARN-7654.015.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

Reply via email to