Mailing-List: contact issues-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
Date: Wed, 16 Aug 2017 19:14:00 +0000 (UTC)
From: "Benjamin Mahler (JIRA)" <jira@apache.org>
To: issues@mesos.apache.org
Message-ID: <JIRA.13072509.1494950911000.46751.1502910840216@Atlassian.JIRA>
In-Reply-To: <JIRA.13072509.1494950911000@Atlassian.JIRA>
References: <JIRA.13072509.1494950911000@Atlassian.JIRA> <JIRA.13072509.1494950911688@jira-lw-us.apache.org>
Subject: [jira] [Updated] (MESOS-7513) Expose the container sandbox path to
 users via the API.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 16 Aug 2017 19:14:07 -0000


     [ https://issues.apache.org/jira/browse/MESOS-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Mahler updated MESOS-7513:
-----------------------------------
    Description: 
Currently, only the agent exposes the executor sandbox via a {{directory}} field in the executor JSON for the v0 API. The master's v0 API and all of the v1 API do not expose the executor sandbox at all.

As a result, users reverse engineer the logic for generating the path and use it in their scripts. To add to the difficulty, the path currently includes the agent's work directory which is only obtainable from the agent endpoints (i.e. {{/<agent_work_directory>/frameworks/<FID>/executors/<EID>}}) rather than exposing a virtual path (i.e. {{/frameworks/<FID>/executors/<EID>}}), like we did for {{/slave/log}} and {{/master/log}}.

We should expose the executor sandbox directory to users consistently in both the master and agent v0/v1 APIs, as well as simplify the path format so that users don't know about the agent's work directory.

This also needs to work for nested containers.

  was:
Currently, there is no public API for getting the path to the sandbox of a running container. This leads to folks reverse engineering the Mesos logic for generating the path and then using it in their scripts. This is already done by the Mesos Web UI and the DC/OS CLI. This is prone to errors if the Mesos path logic changes in the upcoming versions.

We should introduce a new calls on the v1 Agent API; {{GET_CONTAINER_SANDBOX_PATH}}/{{GET_EXECUTOR_SANDBOX_PATH}} to get the path to a running container (can be nested) and another call to get the path to the executor sandbox.

        Summary: Expose the container sandbox path to users via the API.  (was: Consider introducing an API call to get the sandbox of a running container.)

> Expose the container sandbox path to users via the API.
> -------------------------------------------------------
>
>                 Key: MESOS-7513
>                 URL: https://issues.apache.org/jira/browse/MESOS-7513
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Anand Mazumdar
>              Labels: mesosphere
>
> Currently, only the agent exposes the executor sandbox via a {{directory}} field in the executor JSON for the v0 API. The master's v0 API and all of the v1 API do not expose the executor sandbox at all.
> As a result, users reverse engineer the logic for generating the path and use it in their scripts. To add to the difficulty, the path currently includes the agent's work directory which is only obtainable from the agent endpoints (i.e. {{/<agent_work_directory>/frameworks/<FID>/executors/<EID>}}) rather than exposing a virtual path (i.e. {{/frameworks/<FID>/executors/<EID>}}), like we did for {{/slave/log}} and {{/master/log}}.
> We should expose the executor sandbox directory to users consistently in both the master and agent v0/v1 APIs, as well as simplify the path format so that users don't know about the agent's work directory.
> This also needs to work for nested containers.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)