Re: Accessing stdout/stderr of a task programmattically?

2015-01-23 Thread David Greenberg
Thank you very much! That answers all my questions. On Thu, Jan 22, 2015 at 9:35 PM, Niklas Nielsen nik...@mesosphere.io wrote: First off, you can only do this per executor - not per task. To my understanding, the webui just picks up the executor directory from the slave state.json, but the

Re: Accessing stdout/stderr of a task programmattically?

2015-01-22 Thread Niklas Nielsen
First off, you can only do this per executor - not per task. To my understanding, the webui just picks up the executor directory from the slave state.json, but the container id should also be available there. Here is a snippet from a run of a echo 'foobar' baz.txt job: The slave state endpoint:

Re: Accessing stdout/stderr of a task programmattically?

2015-01-21 Thread David Greenberg
Is it possible to know the container_id prior when you submit the TaskInfo? If not, how can you find it out? On Wed, Jan 21, 2015 at 1:17 PM, Ian Downes idow...@twitter.com wrote: The final component is the container_id. Take a look in src/slave/paths.hpp to see the directory layout. On Wed,

Re: Accessing stdout/stderr of a task programmattically?

2015-01-21 Thread Ian Downes
The final component is the container_id. Take a look in src/slave/paths.hpp to see the directory layout. On Wed, Jan 21, 2015 at 8:50 AM, David Greenberg dsg123456...@gmail.com wrote: So, I've looked into this more, and the UUID in runs doesn't appear appear to be the task-id, executor-id, or

Re: Accessing stdout/stderr of a task programmattically?

2015-01-21 Thread David Greenberg
So, I've looked into this more, and the UUID in runs doesn't appear appear to be the task-id, executor-id, or framework-id. do you have any idea what it could be? On Tue, Jan 13, 2015 at 5:21 PM, David Greenberg dsg123456...@gmail.com wrote: Thank you for your answers! On Tue, Jan 13, 2015 at

Re: Accessing stdout/stderr of a task programmattically?

2015-01-21 Thread Ian Downes
No, the container id is generated by the slave when it launches the executor for a task (see Framework::launchExecutor() in src/slave/slave.cpp). However, the 'latest' symlink will point to the most recent container_id directory so you can likely just use that unless your framework is re-using

Re: Accessing stdout/stderr of a task programmattically?

2015-01-21 Thread David Greenberg
It seems that if I take the URL that the Download button for stderr points to and curl it, I get the file. But, if I change the container_id to latest instead of the UUID, then I get a 404. Is there another way to resolve what the container_id is, since it seems critical to get files

Re: Accessing stdout/stderr of a task programmattically?

2015-01-13 Thread Tomas Barton
Have a look at mesos.cli: https://pypi.python.org/pypi/mesos.cli/0.1.3 you can easily do mesos tail {task id} and access log file on any slave machine or connect to machine where is given task running. On 13 January 2015 at 22:48, David Greenberg dsg123456...@gmail.com wrote: I was trying

Re: Accessing stdout/stderr of a task programmattically?

2015-01-13 Thread Tim Chen
You can get the slave_id, framework_id and executor_id of a task all from state.json. ie: - { - executor_id: 20141231-115728-16777343-5050-49193-S0, - framework_id: 20141231-115728-16777343-5050-49193-, - id: 1, - labels: [ ], - name: Task 1, -

Re: Accessing stdout/stderr of a task programmattically?

2015-01-13 Thread David Greenberg
Thank you for your answers! On Tue, Jan 13, 2015 at 5:15 PM, Tim Chen t...@mesosphere.io wrote: You can get the slave_id, framework_id and executor_id of a task all from state.json. ie: - { - executor_id: 20141231-115728-16777343-5050-49193-S0, - framework_id: