[jira] [Commented] (MESOS-3712) --launcher_dir flag is not picked up when running health-checks

2015-10-16 Thread Jay Taylor (JIRA)

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

Jay Taylor commented on MESOS-3712:
---

This ticket should be merged into 
https://issues.apache.org/jira/browse/MESOS-3738.  I've tested the patch in 
3738 and it fixed all broken aspects of health-check invocation.

> --launcher_dir flag is not picked up when running health-checks
> ---
>
> Key: MESOS-3712
> URL: https://issues.apache.org/jira/browse/MESOS-3712
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Affects Versions: 0.24.1, 0.25.0
> Environment: Ubuntu Linux x64
>Reporter: Jay Taylor
>  Labels: containerizer, mesosphere, tech-debt
>
> Mesos configuration flags are one-way and aren't expanded to their 
> corresponding MESOS_ENV variable.
> The {{MESOS_LAUNCHER_DIR}} however, is necessary [here| 
> https://github.com/apache/mesos/blob/master/src/docker/executor.cpp#L573-L576]:
> {code}
>   const Option envPath = os::getenv("MESOS_LAUNCHER_DIR");
>   string path =
> envPath.isSome() ? envPath.get()
>  : os::realpath(Path(argv[0]).dirname()).get();
> {code}
> when the executor needs to resolve the path to run, for example, 
> health-checks.
> Instead of the passed-in argument {{argv[0]}} (which contains the Agent's 
> {{--work_dir}} instead) is the path that ends up being used.
> How can the requisite MESOS_LAUNCHER_DIR env var be available when 
> {{docker/executor.cpp}} (a child process of {{mesos-slave}}) attempts to read 
> it?
> 
> The relevant email thread is here:
> http://www.mail-archive.com/user@mesos.apache.org/msg04794.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MESOS-3712) --launcher_dir flag is not picked up when running health-checks

2015-10-13 Thread Marco Massenzio (JIRA)

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

Marco Massenzio commented on MESOS-3712:


I've updated the description / title of the issue, to narrow down its scope: 
{{Flags}} do what they are supposed to do (read the environment for flags, then 
the command line) and set the various internal options accordingly - expecting 
them to propagate the flags to the environment, so other parts of the code can 
pick them up, would be an "encroaching of concerns" in my view.

A better strategy, would be to find ways in which the executor can be passed an 
option/configuration argument, so that it finds the launcher dir, without 
having to look into the environment (which, as we have seen, does not work).

> --launcher_dir flag is not picked up when running health-checks
> ---
>
> Key: MESOS-3712
> URL: https://issues.apache.org/jira/browse/MESOS-3712
> Project: Mesos
>  Issue Type: Bug
>  Components: slave
>Affects Versions: 0.24.1, 0.25.0
> Environment: Ubuntu Linux x64
>Reporter: Jay Taylor
>Assignee: Marco Massenzio
>  Labels: containerizer, mesosphere, tech-debt
>
> Mesos configuration flags are one-way and aren't expanded to their 
> corresponding MESOS_ENV variable.
> The {{MESOS_LAUNCHER_DIR}} however, is necessary [here| 
> https://github.com/apache/mesos/blob/master/src/docker/executor.cpp#L573-L576]:
> {code}
>   const Option envPath = os::getenv("MESOS_LAUNCHER_DIR");
>   string path =
> envPath.isSome() ? envPath.get()
>  : os::realpath(Path(argv[0]).dirname()).get();
> {code}
> when the executor needs to resolve the path to run, for example, 
> health-checks.
> Instead of the passed-in argument {{argv[0]}} (which contains the Agent's 
> {{--work_dir}} instead) is the path that ends up being used.
> How can the requisite MESOS_LAUNCHER_DIR env var be available when 
> {{docker/executor.cpp}} (a child process of {{mesos-slave}}) attempts to read 
> it?
> 
> The relevant email thread is here:
> http://www.mail-archive.com/user@mesos.apache.org/msg04794.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)