You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Andrew Schwartzmeyer (JIRA)" <ji...@apache.org> on 2018/01/12 22:43:00 UTC

[jira] [Created] (MESOS-8443) Fix Docker Containerizer PATH on Windows so Docker is usable

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)