From reviews-return-64927-apmail-mesos-reviews-archive=mesos.apache.org@mesos.apache.org Thu Aug 17 04:41:35 2017 Return-Path: X-Original-To: apmail-mesos-reviews-archive@minotaur.apache.org Delivered-To: apmail-mesos-reviews-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AD1C21A788 for ; Thu, 17 Aug 2017 04:41:35 +0000 (UTC) Received: (qmail 7981 invoked by uid 500); 17 Aug 2017 04:41:35 -0000 Delivered-To: apmail-mesos-reviews-archive@mesos.apache.org Received: (qmail 7341 invoked by uid 500); 17 Aug 2017 04:41:35 -0000 Mailing-List: contact reviews-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: reviews@mesos.apache.org Delivered-To: mailing list reviews@mesos.apache.org Received: (qmail 7318 invoked by uid 99); 17 Aug 2017 04:41:34 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Aug 2017 04:41:34 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 49192C3E59; Thu, 17 Aug 2017 04:41:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.201 X-Spam-Level: **** X-Spam-Status: No, score=4.201 tagged_above=-999 required=6.31 tests=[DKIM_ADSP_CUSTOM_MED=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, NML_ADSP_CUSTOM_MED=1.2, RP_MATCHES_RCVD=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 15rzwLBmBEgc; Thu, 17 Aug 2017 04:41:33 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 7DED75F5B3; Thu, 17 Aug 2017 04:41:32 +0000 (UTC) Received: from reviews.apache.org (unknown [10.41.0.12]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D34E3E0114; Thu, 17 Aug 2017 04:41:31 +0000 (UTC) Received: from reviews-vm2.apache.org (localhost [IPv6:::1]) by reviews.apache.org (ASF Mail Server at reviews-vm2.apache.org) with ESMTP id E14C1C40495; Thu, 17 Aug 2017 04:41:30 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============4401461752457164951==" MIME-Version: 1.0 Subject: Re: Review Request 61693: Fixed a bug around the `kill()` not removing active containers. From: Jie Yu To: =?utf-8?q?Gast=C3=B3n_Kleiman?= , Vinod Kone , Gilbert Song Cc: Anand Mazumdar , Jie Yu , mesos Date: Thu, 17 Aug 2017 04:41:29 -0000 Message-ID: <20170817044129.51969.79871@reviews-vm2.apache.org> X-ReviewBoard-URL: https://reviews.apache.org/ Auto-Submitted: auto-generated Sender: Jie Yu X-ReviewGroup: mesos X-Auto-Response-Suppress: DR, RN, OOF, AutoReply X-ReviewRequest-URL: https://reviews.apache.org/r/61693/ X-Sender: Jie Yu References: <20170816172712.51981.26787@reviews-vm2.apache.org> In-Reply-To: <20170816172712.51981.26787@reviews-vm2.apache.org> Reply-To: Jie Yu X-ReviewRequest-Repository: mesos --===============4401461752457164951== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61693/#review183101 ----------------------------------------------------------- src/slave/containerizer/composing.cpp Lines 656-657 (patched) Hum, this does not look like the right solution to me. How is that different from user manually sending a `SIGKILL` to the leading process of the container, triggering a reap? Don't you have the same problem in that case? Why we do a special case here? A reap event should trigger a destroy of the container, leading to `wait` being returned. The component waiting for the container to terminate will then call destroy, causing the corresponding container in the composing containerizer being cleaned up. - Jie Yu On Aug. 16, 2017, 5:27 p.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61693/ > ----------------------------------------------------------- > > (Updated Aug. 16, 2017, 5:27 p.m.) > > > Review request for mesos, Gastón Kleiman, Gilbert Song, and Vinod Kone. > > > Repository: mesos > > > Description > ------- > > The composing containerizer relies on users invoking `destroy()` > for removing the container from the list of active containers. > However, when using `kill()` the relevant containerizer just > reaps the container without notifying the composing containerizer > i.e., there is no `destroy()` invocation from the user. This change > chains on the `wait()` future to invoke `destroy()` that > eventually does the cleanup. > > > Diffs > ----- > > src/slave/containerizer/composing.cpp f1a9c3d08b408aa61198f4042b9274df88b789ea > > > Diff: https://reviews.apache.org/r/61693/diff/1/ > > > Testing > ------- > > sudo make check (tests pass) > > > Thanks, > > Anand Mazumdar > > --===============4401461752457164951==--