[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16400676#comment-16400676
]
Jason Lowe commented on YARN-7654:
----------------------------------
Thanks for the patch! Switching the code to execv docker instead of popen
docker is going to be a fairly extensive change that isn't directly tied to
supporting an entry point. Would it make more sense to track the execv effort
as a separate JIRA?
What base should be used for the patch? I couldn't apply it to trunk,
branch-3.1, or branch-3.0.
bq. I am currently running into a problem that after docker is started, the
existing logic for detecting docker exit is not working.
I couldn't tell from the patch what the problem would be. If I can get the
patch applied and some more details on how it behaves when it doesn't work I
may be able to help debug.
bq. I am concerned that we are using popen for docker launch for non-entry
point version, it actually spawn a shell underneath.
Yes, popen opens up the possibility of the shell doing us "favors" that we
really do not want. It would be safer to avoid it.
bq. We might need to convert the output buffer from char array to char pointer
array to avoid chopping strings in the middle.
This is a necessity. By serializing multiple values into a String and then
needing to rediscover the individual values later, we're opening up the
possibility that the arguments will be mishandled based on the contents of the
arguments accidentally looking like separator characters. That's one of the
many dangers of running the shell instead of execv directly which we're trying
to avoid. If we're going to be serious about leveraging execv for security and
correctness in light of untrusted data in the arguments then building up the
command line for execv shouldn't be serialzing and deserializing through String.
As a bonus for going through execv directly, the whole quoting and appending
and sanitizing argument logic seems unnecessary at that point. We can just
pass these values straight through to the docker command for interpretation by
Docker rather than worrying about how to quote them properly so the shell
doesn't butcher them on the way through.
Why does the code not check for an execv error and instead exits with a success
code? It should log the strerror of the execv failure and exit with a failure
code instead.
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
