[
https://issues.apache.org/jira/browse/YARN-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812722#comment-16812722
]
Eric Yang edited comment on YARN-7848 at 4/8/19 7:25 PM:
---------------------------------------------------------
{quote}Thanks for the update, Eric Yang! On the java side, it looks like
DockerRmCommand is invoked in 2 different places. Could we maintain the
original constructor with no force and then add an additional constructor with
a force parameter? We could then change the 2 invocations to use the new
constructor with setting force to true.{quote}
I can preserve existing constructor without force. Passing optional parameter
to container-executor for removing container is slightly dicey at this point.
The accepting parameters are:
{code}container-executor --remove-docker-container [hierarchy]
<container_id>{code}
What we want is:
{code}container-executor --remove-docker-container [hierarchy] [force]
<container_id>{code}
Changing this can have dicey outcome and not backward compatible. I am likely
to have to use cmd file serialization structure to pass the force option from
Java to container-executor for safety reasons.
{code}container-executor --run-docker <command-file>{code}
This will leave a lot of debris and dead code that others may pick up and use
it incorrectly. I am not sure passing this flag from Java is good for long
term maintenance. Keeping it simple is probably better. Thoughts [~ebadger]
[~Jim_Brennan] [~shaneku...@gmail.com] [~billie.rinaldi]?
was (Author: eyang):
{quote}Thanks for the update, Eric Yang! On the java side, it looks like
DockerRmCommand is invoked in 2 different places. Could we maintain the
original constructor with no force and then add an additional constructor with
a force parameter? We could then change the 2 invocations to use the new
constructor with setting force to true.{quote}
I can preserve existing constructor without force. Passing optional parameter
to container-executor for removing container is slightly dicey at this point.
The accepting parameters are:
```container-executor --remove-docker-container [hierarchy] <container_id>```
What we want is:
```container-executor --remove-docker-container [hierarchy] [force]
<container_id>```
Changing this can have dicey outcome and not backward compatible. I am likely
to have to use cmd file serialization structure to pass the force option from
Java to container-executor for safety reasons.
```container-executor --run-docker <command-file>```
This will leave a lot of debris and dead code that others may pick up and use
it incorrectly. I am not sure passing this flag from Java is good for long
term maintenance. Keeping it simple is probably better. Thoughts [~ebadger]
[~Jim_Brennan] [~shaneku...@gmail.com] [~billie.rinaldi]?
> Force removal of docker containers that do not get removed on first try
> -----------------------------------------------------------------------
>
> Key: YARN-7848
> URL: https://issues.apache.org/jira/browse/YARN-7848
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Eric Badger
> Assignee: Eric Yang
> Priority: Major
> Labels: Docker
> Attachments: YARN-7848.001.patch, YARN-7848.002.patch
>
>
> After the addition of YARN-5366, containers will get removed after a certain
> debug delay. However, this is a one-time effort. If the removal fails for
> whatever reason, the container will persist. We need to add a mechanism for a
> forced removal of those containers.
--
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
