You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Qian Zhang (Jira)" <ji...@apache.org> on 2019/10/18 07:28:00 UTC

[jira] [Comment Edited] (MESOS-9964) Support destroying UCR containers in provisioning state

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

Qian Zhang edited comment on MESOS-9964 at 10/18/19 7:27 AM:
-------------------------------------------------------------

Master:

commit 33c61a1907129126f3b2e37b1f53827a04e89a34
 Author: Qian Zhang 
 Date: Fri Oct 11 22:05:14 2019 +0800

Supported destroying UCR container in `PROVISIONING` state.

Previously in MESOS-3736, we made Docker store support pulling same
 image simultaneously which is a performance improvement, however it
 may cause an issue: If the pulling hangs somehow, all the subsequent
 pulling request for the same image will hang as well, and as a result
 the container destroy will also hang since destroy has to wait for
 provisioning to finish, see MESOS-4985 for details.

So in this patch we removed that performance improvement and made UCR
 can destroy the container which is being provisioned, i.e., UCR will
 discard the container provisioning and then keep doing the container
 destroy. And we also improved Docker fetcher plugin so that when
 container provisioning is discarded the `curl` process used to fetch
 manifest or blob will be killed immediately.

Review: [https://reviews.apache.org/r/71608]

commit b5929429c9638d6c0d03db6d44ac673d67e49a8c
 Author: Qian Zhang 
 Date: Thu Oct 17 17:41:10 2019 +0800

Improved logging in Docker store and registry puller.

Review: [https://reviews.apache.org/r/71629]

1.9.x:

commit a1c6feeb266a8756a63a2de005d5b97f04baa403
Author: Qian Zhang <zh...@gmail.com>
Date: Thu Oct 17 17:41:10 2019 +0800

Improved logging in Docker store and registry puller.
 
 Review: https://reviews.apache.org/r/71629

commit ce518a4bf3b1a5f1fd2dc8e907f2e6622f251537
Author: Qian Zhang <zh...@gmail.com>
Date: Fri Oct 11 22:05:14 2019 +0800

Supported destroying UCR container in `PROVISIONING` state.
 
 Previously in MESOS-3736, we made Docker store support pulling same
 image simultaneously which is a performance improvement, however it
 may cause an issue: If the pulling hangs somehow, all the subsequent
 pulling request for the same image will hang as well, and as a result
 the container destroy will also hang since destroy has to wait for
 provisioning to finish, see MESOS-4985 for details.
 
 So in this patch we removed that performance improvement and made UCR
 can destroy the container which is being provisioned, i.e., UCR will
 discard the container provisioning and then keep doing the container
 destroy. And we also improved Docker fetcher plugin so that when
 container provisioning is discarded the `curl` process used to fetch
 manifest or blob will be killed immediately.
 
 Review: https://reviews.apache.org/r/71608

1.8.x:

commit 7687f4ea379cbd17b46c54505246018bb1fd9ef3
Author: Qian Zhang <zh...@gmail.com>
Date: Thu Oct 17 17:41:10 2019 +0800

Improved logging in Docker store and registry puller.
 
 Review: https://reviews.apache.org/r/71629

commit 35b594fa209aaa2f8975bdae145233f7ed61c0c8
Author: Qian Zhang <zh...@gmail.com>
Date: Fri Oct 11 22:05:14 2019 +0800

Supported destroying UCR container in `PROVISIONING` state.
 
 Previously in MESOS-3736, we made Docker store support pulling same
 image simultaneously which is a performance improvement, however it
 may cause an issue: If the pulling hangs somehow, all the subsequent
 pulling request for the same image will hang as well, and as a result
 the container destroy will also hang since destroy has to wait for
 provisioning to finish, see MESOS-4985 for details.
 
 So in this patch we removed that performance improvement and made UCR
 can destroy the container which is being provisioned, i.e., UCR will
 discard the container provisioning and then keep doing the container
 destroy. And we also improved Docker fetcher plugin so that when
 container provisioning is discarded the `curl` process used to fetch
 manifest or blob will be killed immediately.
 
 Review: [https://reviews.apache.org/r/71608]

1.7.x:

commit 28d87b7a801c47849f3bf32aaa0e19d7745674de
Author: Qian Zhang <zh...@gmail.com>
Date: Thu Oct 17 17:41:10 2019 +0800

Improved logging in Docker store and registry puller.
 
 Review: https://reviews.apache.org/r/71629

commit d8aeab2952e34ad43d15e4d4907cecacbd309aee
Author: Qian Zhang <zh...@gmail.com>
Date: Fri Oct 11 22:05:14 2019 +0800

Supported destroying UCR container in `PROVISIONING` state.
 
 Previously in MESOS-3736, we made Docker store support pulling same
 image simultaneously which is a performance improvement, however it
 may cause an issue: If the pulling hangs somehow, all the subsequent
 pulling request for the same image will hang as well, and as a result
 the container destroy will also hang since destroy has to wait for
 provisioning to finish, see MESOS-4985 for details.
 
 So in this patch we removed that performance improvement and made UCR
 can destroy the container which is being provisioned, i.e., UCR will
 discard the container provisioning and then keep doing the container
 destroy. And we also improved Docker fetcher plugin so that when
 container provisioning is discarded the `curl` process used to fetch
 manifest or blob will be killed immediately.
 
 Review: https://reviews.apache.org/r/71608


was (Author: qianzhang):
commit 33c61a1907129126f3b2e37b1f53827a04e89a34
Author: Qian Zhang 
Date: Fri Oct 11 22:05:14 2019 +0800

Supported destroying UCR container in `PROVISIONING` state.
 
 Previously in MESOS-3736, we made Docker store support pulling same
 image simultaneously which is a performance improvement, however it
 may cause an issue: If the pulling hangs somehow, all the subsequent
 pulling request for the same image will hang as well, and as a result
 the container destroy will also hang since destroy has to wait for
 provisioning to finish, see MESOS-4985 for details.
 
 So in this patch we removed that performance improvement and made UCR
 can destroy the container which is being provisioned, i.e., UCR will
 discard the container provisioning and then keep doing the container
 destroy. And we also improved Docker fetcher plugin so that when
 container provisioning is discarded the `curl` process used to fetch
 manifest or blob will be killed immediately.
 
 Review: [https://reviews.apache.org/r/71608]

commit b5929429c9638d6c0d03db6d44ac673d67e49a8c
Author: Qian Zhang 
Date: Thu Oct 17 17:41:10 2019 +0800

Improved logging in Docker store and registry puller.
 
 Review: [https://reviews.apache.org/r/71629]

> Support destroying UCR containers in provisioning state
> -------------------------------------------------------
>
>                 Key: MESOS-9964
>                 URL: https://issues.apache.org/jira/browse/MESOS-9964
>             Project: Mesos
>          Issue Type: Improvement
>          Components: containerization
>            Reporter: Qian Zhang
>            Assignee: Qian Zhang
>            Priority: Major
>              Labels: containerization
>             Fix For: 1.7.3, 1.8.2, 1.9.1, 1.10.0
>
>
> Currently when destroying a UCR container, if the container is in provisioning state, we will wait for the provisioner to finish provisioning before we start destroying the container, see [here|https://github.com/apache/mesos/blob/1.9.0/src/slave/containerizer/mesos/containerizer.cpp#L2685:L2693] for details. This may cause the container stuck at destroying, and more seriously it may cause the subsequent containers created from the same image stuck at provisioning state, because if the first container was stuck at pulling the image somehow, the subsequent containers have to wait for the puller to finish the pulling, see [here|https://github.com/apache/mesos/blob/1.9.0/src/slave/containerizer/mesos/provisioner/docker/store.cpp#L341:L345] for details.
> So we'd better to support destroying the container in provisioning state so that the subsequent containers created from the same image will not be affected.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)