mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jie Yu (JIRA)" <>
Subject [jira] [Commented] (MESOS-6467) Build a Container I/O Switchboard
Date Tue, 29 Nov 2016 22:14:58 GMT


Jie Yu commented on MESOS-6467:

commit 4dcc42790752b8e26d5e5e9d96b9d082baec3f91
Author: Kevin Klues <>
Date:   Tue Nov 29 13:50:02 2016 -0800

    Added helper to get the io switchboard server address.

    For now, the io switchboard server will always hosted on a unix domain
    socket. The path limit for a unix domain socket is 100 bytes, so we
    can't just use a file in our runtime directory as the socket file we
    connect to. Instead, we store the path to the socket file in our
    runtime directory and read it from there.


> Build a Container I/O Switchboard
> ---------------------------------
>                 Key: MESOS-6467
>                 URL:
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Kevin Klues
>            Assignee: Kevin Klues
>              Labels: debugging, mesosphere
> In order to facilitate attach operations for a running container, we plan to introduce
a new component into Mesos known as an “I/O switchboard”. The goal of this switchboard
is to allow external components to *dynamically* interpose on the {{stdin}}, {{stdout}} and
{{stderr}} of the init process of a running Mesos container. It will be implemented as a per-container,
stand-alone process launched by the mesos containerizer at the time a container is first launched.
> Each per-container switchboard will be responsible for the following:
>  * Accepting a single dynamic request to register an fd for streaming data to the {{stdin}}
of a container’s init process.
>  * Accepting *multiple* dynamic requests to register fds for streaming data from the
{{stdout}} and {{stderr}} of a container’s init process to those fds.
>  * Allocating a pty for the new process (if requested), and directing data through the
master fd of the pty as necessary.
>  * Passing the *actual* set of file descriptors that should be dup’d onto the {{stdin}},
{{stdout}} and {{stderr}} of a container’s init process back to the containerizer. 
> The idea being that the switchboard will maintain three asynchronous loops (one each
for {{stdin}}, {{stdout}} and {{stderr}}) that constantly pipe data to/from a container’s
init process to/from all of the file descriptors that have been dynamically registered with

This message was sent by Atlassian JIRA

View raw message