Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
Date: Tue, 18 Mar 2014 18:15:47 +0000 (UTC)
From: "Timothy St. Clair (JIRA)" <jira@apache.org>
To: dev@mesos.apache.org
Message-ID: <JIRA.12701276.1394730047259.98871.1395166547713@arcas>
In-Reply-To: <JIRA.12701276.1394730047259@arcas>
References: <JIRA.12701276.1394730047259@arcas>
Subject: [jira] [Commented] (MESOS-1094) Introduce pid namespace abstraction
 to subprocess
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Timothy St. Clair commented on MESOS-1094:
------------------------------------------

FWIW In the past we've done configure+compile-checks to determine unshare semantics & capabilities, then dropped a config.h file with enough preprocessor flags to do the right thing.  

> Introduce pid namespace abstraction to subprocess
> -------------------------------------------------
>
>                 Key: MESOS-1094
>                 URL: https://issues.apache.org/jira/browse/MESOS-1094
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Niklas Quarfot Nielsen
>            Assignee: Niklas Quarfot Nielsen
>
> Introducing PID namespacing could simplify signal escalation and process control in for example the command executor and pluggable containerizer.
> Along the lines of the Fork Exec abstraction in stout, I suggest that we add an abstraction for Linux namespaces.
> LinuxNamespace(PID /* | IPC | mount | ...*/, Fork(Exec("sleep 10"))
> It would be guarded or add convenience methods to ensure system support, for example bool LinuxNamespace::supports(PID /* | IPC | ... */) or simply let the namespace fall back to regular fork/exec.
> I have a proof-of-concept version of the command executor which use PID namespaces (in combination with delay/escalation), and it feels like details around stack allocation and management could be captured in a new abstraction and make it a neat and nice subsystem to use.


--
This message was sent by Atlassian JIRA
(v6.2#6252)