[
https://issues.apache.org/jira/browse/MESOS-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3712:
-----------------------------------
Description:
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<string> 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/[email protected]/msg04794.html
was:
Mesos configuration flags are one-way and aren't expanded to their
corresponding MESOS_ENV variable.
This can cause various bugs due to lack of env var propagation.
For example:
The MESOS_LAUNCHER_DIR env var does not seem get picked up here:
https://github.com/apache/mesos/blob/master/src/docker/executor.cpp#L573-L576:
const Option<string> envPath = os::getenv("MESOS_LAUNCHER_DIR");
string path =
envPath.isSome() ? envPath.get()
: os::realpath(Path(argv[0]).dirname()).get();
And argv[0] (which contains the slave work dir) is the path that ends up being
used.
I'm having trouble understanding how flags defined in
mesos::internal::slave::Flags::Flags (src/slave/flags.[ch]pp) are propagated or
expanded to MESOS_<flag_in_caps> environment variables. Can you confirm if
such a mechanism exists and if so where it is?
Otherwise, if my understanding is correct and such a mechanism doesn't exist:
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?
----
To which Marco replied:
> Jay:
you hit the nail on the head: the direction is definitely one-way (from
> MESOS_ENV var to Flag) and we don't reflect --flag back into the
> MESOS_FLAG env var.
> Others more familiar with the matter may correct me, but it looks like you
> have uncovered a bug in the executor code: could you please file a Jira for
> us to look into?
> It seems to me that, at present, the only workaround is for you would be to
> set
> the MESOS_LAUNCHER_DIR env var, as the flag won't be picked by the
> executor.
(Note: I've pasted the above context as I'm not sure if the list picked up all
of the exchange)
Here is the relevant discussion thread on the users mailing list:
http://www.mail-archive.com/[email protected]/msg04794.html
> --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<string> 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/[email protected]/msg04794.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
