Return-Path: X-Original-To: apmail-aurora-dev-archive@minotaur.apache.org Delivered-To: apmail-aurora-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 90CCF1031F for ; Thu, 22 Oct 2015 15:28:49 +0000 (UTC) Received: (qmail 2303 invoked by uid 500); 22 Oct 2015 15:28:49 -0000 Delivered-To: apmail-aurora-dev-archive@aurora.apache.org Received: (qmail 2262 invoked by uid 500); 22 Oct 2015 15:28:49 -0000 Mailing-List: contact dev-help@aurora.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aurora.apache.org Delivered-To: mailing list dev@aurora.apache.org Received: (qmail 2238 invoked by uid 99); 22 Oct 2015 15:28:49 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Oct 2015 15:28:49 +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 A6AF3C4BFA for ; Thu, 22 Oct 2015 15:28:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id vBJqa73l-ofB for ; Thu, 22 Oct 2015 15:28:42 +0000 (UTC) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 923412074F for ; Thu, 22 Oct 2015 15:28:41 +0000 (UTC) Received: by ioll68 with SMTP id l68so95534637iol.3 for ; Thu, 22 Oct 2015 08:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=t27D5/qCQ/4WiUOEYx4D3qGcClPE5oyesyALgivxwqA=; b=SejCKDJkIM1SnlJk9UbhveoVL4Gk8mVAQSzfO7UMWe2i1KeYkkh3syyV51TGdk346F iWqIrkd905XESlZ2si4JMEhTEIoMTbEuYsGJ0tUn8Jc+zSssF6gBkUgrL94bAQKoa05k ED5stsu3K1pO1pCnvb5fBzb6Zn2iY43wi3RENr3kh/K5jIoHYjWsbAfdpvuaMpoOrzcv Fxd8MgFikQ8n9Fp05At1tfwnUSGd7eNb9gbAtnhAFci9ddcU+DRj16qG/mJIF3kZHQLh h5pRqTiO1/7ObP/FLiaO1KrCl/cOFRjtpa1jsRcuZGQE/ZZnfn5lk2ouWKbA2tpS0yR1 jRQQ== MIME-Version: 1.0 X-Received: by 10.107.6.225 with SMTP id f94mr18486247ioi.194.1445527720542; Thu, 22 Oct 2015 08:28:40 -0700 (PDT) Sender: jeffschroed@gmail.com Received: by 10.79.97.2 with HTTP; Thu, 22 Oct 2015 08:28:40 -0700 (PDT) In-Reply-To: References: <1445414309661.77792@blue-yonder.com> Date: Thu, 22 Oct 2015 10:28:40 -0500 X-Google-Sender-Auth: VWvAArM6BCeIj00JFAvK9hAKJzc Message-ID: Subject: Re: Unified container support in Aurora From: Jeff Schroeder To: "dev@aurora.apache.org" Content-Type: multipart/alternative; boundary=001a113f8e164bca2b0522b3260b --001a113f8e164bca2b0522b3260b Content-Type: text/plain; charset=UTF-8 Ah excellent. I was a bit confused as I know the Tellapart team, which I believe you're a member of, really knows this stack really well. Hopefully you sent that back upstream :) I still see more outages due to weird docker bugs than virtually anything else and am pretty excited to see this support land. This doesn't seem like a discussion that should really happen here though as it is the mesos direction more than Aurora's. Perhaps we should move this to the mesos users list? On Thursday, October 22, 2015, Steve Niemitz wrote: > I'm in fact more familiar with them than I'd like, as I've had to modify > the docker containerizer to support both CFS and correct memory and CPU > stats. ;) > > On Thu, Oct 22, 2015 at 11:09 AM, Jeff Schroeder < > jeffschroeder@computer.org > > wrote: > > > On Thursday, October 22, 2015, Steve Niemitz > > > > > wrote: > > > > > > > > > > because docker's runtime isolation (e.g., cpu, memory, etc) is not > > > > compatible with Mesos's runtime isolation > > > > > > > > > I find that kind of an odd statement, as they both just use cgroups to > > > achieve said isolation. > > > > > > I suspect you aren't familiar with the mesos isolators. Yes they both use > > control groups under the hood, but they are different. They are also > > plugins that fit in with the rest of mesos, docker does not. I'm quite > > excited about this as the docker daemon is far and above the least stable > > part of my infrastructure. > > > > These are native mesos modules which means mesos can track and manage the > > resource consumption: > > http://mesos.apache.org/documentation/latest/network-monitoring/ > > > > > > -- > > Text by Jeff, typos by iPhone > > > -- Text by Jeff, typos by iPhone --001a113f8e164bca2b0522b3260b--