[
https://issues.apache.org/jira/browse/YARN-9561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924470#comment-16924470
]
Eric Yang commented on YARN-9561:
---------------------------------
{quote}There's currently a debug line at the end of
RuncContainerRuntime.launchContainer() that will get printed to the nodemanager
that has the entire JSON that was used to launch the container-executor. I
didn't want to print this to info since the JSON is very large and scary
looking. What do you think?{quote}
I was thinking to print the config.json instead of runc-config.json. This
provide ability to verify that no incorrect syntax was passed onto runc. If
this is too wordy, a line of the current stage of the execution would help to
know that runc command is called.
{quote}I'm confused as to what you're asking here. In this comment on YARN-9560
you didn't want the configs to be mapped together. Now it sounds like you want
there to be integration. Could you clarify this for me?{quote}
Direct mapping of the config key is not a good idea because the parameter value
might look different even though their purpose might be the same. For example,
YARN_CONTAINER_RUNTIME_DOCKER_RUN_OVERRIDE_DISABLE is to support Docker entry
point, but that concept does not exist with runc. If user does not want the
wrapper launch_container.sh and like to specify the launch command directly,
configuration mechanism defines how to control the container via either
properties or environment variable to control those behaviors. The
documentation is a list of available customizable controls that is available to
application developers. Similar set of controls needs to be developed for
application developer to configure runc containers.
{quote}
If you have specific suggestions on things that you would like to be added,
feel free to create JIRAs. Otherwise I'll create a list at some point.
{quote}
The configurable properties is the suggested list to start. Mount point is the
most important one. The current patch offers its own implementation of default
mount point. The app submission REST API offers a different way to mount
devices with acl check. I think the second approach provides better security.
What is the right way to ensure the two techniques are complementary of each
other and reduce divergence? Can someone submit a job.xml that customize
yarn.nodemanager.runtime.linux.runc.default-rw-mounts? It looks like possible
today, but should it be allowed?
> Add C changes for the new RuncContainerRuntime
> ----------------------------------------------
>
> Key: YARN-9561
> URL: https://issues.apache.org/jira/browse/YARN-9561
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Eric Badger
> Assignee: Eric Badger
> Priority: Major
> Attachments: YARN-9561.001.patch, YARN-9561.002.patch,
> YARN-9561.003.patch, YARN-9561.004.patch
>
>
> This JIRA will be used to add the C changes to the container-executor native
> binary that are necessary for the new RuncContainerRuntime. There should be
> no changes to existing code paths.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
