[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472318#comment-16472318
]
Eric Yang commented on YARN-7654:
---------------------------------
[~jlowe] Thanks for the reply. Some answers:
{quote}
In DockerProviderService#buildContainerLaunchContext it's calling
processArtifact then super.buildContainerLaunchContext, but the parent's
buildContainerLaunchContext calls processArtifact as well. Is the double-call
intentional?
{quote}
Not intentional, this is fixed in patch 23.
{quote}Note I'm not sure if we really need to rebuild tokensForSubtitution in
DockerProviderService, I'm just preserving what the patch was doing. AFAICT the
only difference between what the patch had DockerProviderService build for
tokens and what AbstractProviderService builds is the latter is doing a pass
adding ${env} forms of every env var to the map. If DockerProviderService is
supposed to be doing that as well then it can just use the tokenProviderService
arg directly rather than building it from scratch.{quote}
I was able to make the refactoring happen this morning with a clear head. This
is more readable without repeat in patch 23.
> 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
> Labels: Docker
> 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, YARN-7654.016.patch, YARN-7654.017.patch,
> YARN-7654.018.patch, YARN-7654.019.patch, YARN-7654.020.patch,
> YARN-7654.021.patch, YARN-7654.022.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]
