You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Ignasi Barrera (JIRA)" <ji...@apache.org> on 2016/08/30 13:26:20 UTC

[jira] [Commented] (JCLOUDS-1162) DockerComputeServiceAdapter hides cause of container startup failure

    [ https://issues.apache.org/jira/browse/JCLOUDS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449006#comment-15449006 ] 

Ignasi Barrera commented on JCLOUDS-1162:
-----------------------------------------

I'd go for the log & destroy approach, if the logs provide useful info. This will keep the provider consistent with others, and will avoid leaking containers. This shouldn't be an issue, but if using this api against a hosted Docker, that could cause costs to grow without users noticing it. WDYT?

> DockerComputeServiceAdapter hides cause of container startup failure
> --------------------------------------------------------------------
>
>                 Key: JCLOUDS-1162
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1162
>             Project: jclouds
>          Issue Type: Improvement
>          Components: jclouds-compute
>    Affects Versions: 2.0.0
>            Reporter: Josef Cacek
>
> When Docker container startup fails, then the cause is not visible for users, because the container is immediately destroyed.
> I see 2 possible solutions/improvements here:
> * add a container config option to not remove the container if the start fails (or another possible behavior is to not remove the container at all)
> * if container start fails, then read container logs ({{ContainerApi.attach(String, AttachOptions)}}) and log them on some suitable level (IMO somewhere between DEBUG and WARN).
> Following code comes from {{DockerComputeServiceAdapter}} and is responsible for the current behavior:
> {code}
>       logger.debug(">> starting container(%s) with hostConfig(%s)", container.id(), hostConfig);
>       api.getContainerApi().startContainer(container.id(), hostConfig);
>       logger.trace("<< started(%s)", container.id());
>       container = api.getContainerApi().inspectContainer(container.id());
>       if (container.state().exitCode() != 0) {
>          destroyNode(container.id());
>          throw new IllegalStateException(String.format("Container %s has not started correctly", container.id()));
>       }
> // ....
>    @Override
>    public void destroyNode(String id) {
>       api.getContainerApi().removeContainer(id, RemoveContainerOptions.Builder.force(true));
>    }
> {code}
> [~nacx] Which solution do you prefer (config option to not remove container, logging the container logs, both options)?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)