Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[specific ci=3-03-Docker-Compose-Basic] Unbind container in containerRm #6209

Merged
merged 8 commits into from
Sep 7, 2017

Conversation

chengwang86
Copy link
Contributor

Fixes #5948

This PR tries to unbind the container in the before removing the container.

This may potentially degrade the performance of containerRm. However, since the PL will not do anything if the container is already unbound, its impact on performance may be neligible.

@hmahmood
Copy link
Contributor

hmahmood commented Sep 5, 2017

Will this actually solve the issue with kill not actually unbinding the container from the network?

@chengwang86
Copy link
Contributor Author

@hmahmood I think the original issue can be fixed by doing this. The reason why the failure occurs is that the container is removed before it is unbound, and that compose down calls container stop followed by container rm instead of container rm -f. So this PR unbinds the container in the code path where the containerRM() is called without -f.

@chengwang86
Copy link
Contributor Author

Deleting dangling containerVMs from network layer when calling deleteScope is also an option, but it requires that the network layer knows about the status of the exec cache, which violates the isolation of layers.

@hmahmood
Copy link
Contributor

hmahmood commented Sep 5, 2017

So if I call docker kill for a container, it can potentially still be connected to its network afterwards if I don't follow it with an rm?

@hmahmood
Copy link
Contributor

hmahmood commented Sep 5, 2017

Why do we not have a special case for SIGKILL in https://github.com/vmware/vic/blob/master/lib/apiservers/engine/backends/container.go#L634 as we do on the portlayer side (https://github.com/vmware/vic/blob/master/lib/portlayer/exec/container.go#L454), and unbind the container there?

@chengwang86
Copy link
Contributor Author

@hmahmood If docker kill is not followed by docker rm, the container will not be removed from cache and the containerPoweredOff event will finally be processed properly. So the container will be unbound from the network in this case.

The failure occurs because docker kill is followed by docker rm before the event is processed.

About why I didn't have a special case checking SIGKILL in containerKill(), George's opinion was that we should target at a more general set of failures that might occur due to this race condition, instead of only focusing on docker kill. @hickeng Thoughts?

@hmahmood
Copy link
Contributor

hmahmood commented Sep 5, 2017

What about port mappings? Do they also get unmapped when with a kill?

@chengwang86
Copy link
Contributor Author

@hmahmood ContainerKill() calls container_proxy.Signal(), which would unmap the ports if the state is not running. So I think the ports should've been unmapped after docker kill.

In this case, I think I can move unmapPorts() outside of UnbindContainerfFromNetwork().

@chengwang86 chengwang86 requested a review from sflxn September 5, 2017 20:41
default:
return "", InternalServerError(err.Error())
}
} else {
Copy link
Contributor

@anchal-agrawal anchal-agrawal Sep 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think the else block is needed - we can just say

    if err != nil {
        ...
    }

    return ub.Payload.Handle, nil

@@ -835,6 +826,28 @@ func (c *ContainerProxy) Stop(vc *viccontainer.VicContainer, name string, second
return nil
}

func (c *ContainerProxy) UnbindContainerFromNetwork(vc *viccontainer.VicContainer, handle string) (string, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have function comments for exported functions.


handle, err := c.Handle(id, name)
if err != nil {
return err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a docker-typed error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so. It returns either NotFoundError or InternalServerError.

@chengwang86 chengwang86 requested a review from jzt September 5, 2017 21:29
@@ -835,6 +826,27 @@ func (c *ContainerProxy) Stop(vc *viccontainer.VicContainer, name string, second
return nil
}

// UnbindContainerFromNetwork unbinds a container from the networks that it connects to
func (c *ContainerProxy) UnbindContainerFromNetwork(vc *viccontainer.VicContainer, handle string) (string, error) {
defer trace.End(trace.Begin(""))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be worthwhile to trace on the container ID here?

@chengwang86 chengwang86 changed the title [specific ci=1-11-Docker-RM] Unbind container in containerRm [specific ci=3-03-Docker-Compose-Basic] Unbind container in containerRm Sep 5, 2017
Copy link
Contributor

@rajanashok rajanashok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants