You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Eric Yang (JIRA)" <ji...@apache.org> on 2019/04/08 19:26:00 UTC
[jira] [Comment Edited] (YARN-7848) Force removal of docker
containers that do not get removed on first try
[ 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] [~shanekumpf@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] [~shanekumpf@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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org