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 837631825C for ; Fri, 14 Aug 2015 18:39:23 +0000 (UTC) Received: (qmail 79721 invoked by uid 500); 14 Aug 2015 18:39:20 -0000 Delivered-To: apmail-aurora-dev-archive@aurora.apache.org Received: (qmail 79670 invoked by uid 500); 14 Aug 2015 18:39:20 -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 79658 invoked by uid 99); 14 Aug 2015 18:39:20 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Aug 2015 18:39:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 988331AA0B6 for ; Fri, 14 Aug 2015 18:39:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.898 X-Spam-Level: ** X-Spam-Status: No, score=2.898 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=twitter.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 2K1S2WDMe7ht for ; Fri, 14 Aug 2015 18:39:18 +0000 (UTC) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 75F69428F6 for ; Fri, 14 Aug 2015 18:39:18 +0000 (UTC) Received: by qgj62 with SMTP id 62so57332706qgj.2 for ; Fri, 14 Aug 2015 11:39:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=FD9M7/E1jOcUCve9BMAJILkwJswU/fy3h5H8sKdh3Tk=; b=PU4ROJCAZehYF+eAOvIxqWfAKvWJbt/hUwzcLtxac/oRO0bodC0spFod4/DNMruPa/ YICb26lT/xsCeuj7dgzdLstl3cJ2PV6AfDtS/13yGczkOzlK4rNZ1TllcZRMpnW3VVNF +KKMG2OMyyS/8OgBRAjkxk8Pz5ZkrjSRrxeKkTrTpVUL/cWT3KibNRO+uWIPdxIHK36e qbxgdyJ9hz7fa6mAhv8JlULnmiAHLlpC8q7bG1By2oLsQS4Thh1QEvbf4ysOPZYMKGxs Kvvpr1BVu2vR7vG78ckEABg3XwKtx7LMh8QZNlb1B5v8iLiWD6G79nzawgGp1vZCbFgy 0PuQ== X-Gm-Message-State: ALoCoQlgTIOyiXJFeVROGzA+GKcAI6ZbrFBxXGr7a5LUD/EN+DCzOqTOjI+jxr4Spjvo1DbqnoEF MIME-Version: 1.0 X-Received: by 10.140.46.4 with SMTP id j4mr54550884qga.17.1439577557920; Fri, 14 Aug 2015 11:39:17 -0700 (PDT) Received: by 10.140.108.67 with HTTP; Fri, 14 Aug 2015 11:39:17 -0700 (PDT) Date: Fri, 14 Aug 2015 11:39:17 -0700 Message-ID: Subject: Improvements to container support with custom executor From: Kevin Sweeney To: "user@mesos.apache.org" Cc: dev@aurora.apache.org Content-Type: multipart/alternative; boundary=001a113a8068f78f43051d49c4e3 --001a113a8068f78f43051d49c4e3 Content-Type: text/plain; charset=UTF-8 (cross-posting for a wider audience) Hi folks, With mesos-0.23.0 it looks like a new dependency made it in for TLS support. While this is fine in theory it actually makes the Docker Containerizer story very difficult to reason about. Here's the situation: Aurora uses a custom Python executor for its tasks. Because of the design of the containerizer the executor runs in the context of the container. This means that the container has to be able to run the executor (in practice this means it needs a python2.7 installation and some shared libraries libmesos links to). Since most containers don't contain Aurora's executor, Aurora hacked around this by using the executor in $MESOS_SANDBOX plus a requirement that hosted containers be able to run the executor. However, with the upgrade to mesos-0.23.0 the containers that could run the 0.22.0 executor no longer work due to the new dependency on libcurl-nss. This is not a problem limited to Docker - I don't see how this design will work with *any* container runtime - we can never upgrade the executor without upgrading all the containers to contain its new dependencies, which at a minimum means we must rebuild them whenever mesos gains a new dependency. Does anyone with more experience with these APIs have a suggestion here? It seems we need to make the executor run in the context of the host OS and aware of the container (or maybe we have mesos launch a container with the executor+its dependencies and have it launch a child container). -- Kevin Sweeney @kts --001a113a8068f78f43051d49c4e3--