Andrew Schwartzmeyer created MESOS-8443:
-------------------------------------------
Summary: Fix Docker Containerizer PATH on Windows so Docker is
usable
Key: MESOS-8443
URL: https://issues.apache.org/jira/browse/MESOS-8443
Project: Mesos
Issue Type: Bug
Components: docker
Affects Versions: 1.5.0
Environment: Windows with containers
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
Priority: Blocker
When fixing MESOS-6816 (Allows frameworks to overwrite system environment
variables) for Windows, we reconciled the Windows executor behave with that of
Linux. Previously, Windows would explicitly query for the system environment,
and set that for the executor. However, this is incorrect from Mesos's
standpoint, which explicitly constructs a "pristine" environment for the
executor. On Linux, this is not really a problem, as the
{{os::host_default_path()}} tends to always contain the binaries users may run
(including {{docker}}), since the paradigm on Linux is that packages install
their binary to e.g. {{/usr/local/bin}} or {{/usr/bin}}. However, on Windows,
"packages" / software _do not_ install binaries to the default system {{PATH}}.
Instead, the system {{PATH}} is modified to include the software's directory.
The unfortunate case is that this true for Docker. When Docker is installed on
Windows, {{docker.exe}} _does not_ exist in the default path, instead some
folder under Program Files is added to the system {{PATH}} environment (and
this folder changes based on client vs server installs; that is, it is
inconsistent). This means that the "correct" behavior of the execuctor
(specifically when using the Docker containerizer) pretty much breaks on
Windows, as the containerizer is unusable (it cannot find {{docker.exe}})
without the user manually finding the {{PATH}} and passing it on the
command-line (or in the task info).
More unfortunately, users of Mesos on Windows are already depending on this
buggy "feature" and so currently 1.5.0 will break all deployments of Mesos on
Windows using containers. Hence this is a blocking bug.
Joseph Wu and I came to the conclusion that the most unobtrusive fix is to
append the folder which contains {{docker.exe}} (found by running
{{os::which(docker)}} in the context of the agent, which still has the system
environment) to the {{PATH}} environment that will be used for the executor. So
we'll maintain the "pristine" environment, but also have Docker in the path (if
it exists). This will not break if someone passes an absolute path to the
Docker executable, or if someone manually sets the {{PATH}} environment.
There is the edge case that Docker was installed and then subsequently renamed.
However, we're not going to handle this, as we're trying to make a reasonable
{{PATH}} variable, which is {{os::host_default_path()}} + "typical Docker
installation". If they rename {{docker.exe}}, they're on their own to pass it
or pass the environment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
