mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akash Gupta <akash-gu...@hotmail.com>
Subject Re: Review Request 65872: Windows: Fixed location of Docker's `config.json` file.
Date Fri, 02 Mar 2018 00:06:03 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65872/#review198489
-----------------------------------------------------------


Ship it!




Ship It!

- Akash Gupta


On March 1, 2018, 11:57 p.m., Andrew Schwartzmeyer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65872/
> -----------------------------------------------------------
> 
> (Updated March 1, 2018, 11:57 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Jeff Coffler, and Joseph Wu.
> 
> 
> Bugs: MESOS-8619
>     https://issues.apache.org/jira/browse/MESOS-8619
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Per MESOS-8619, Docker checks `$USERPROFILE/.docker/config.json`
> instead of `$HOME`. Mesos overrides this environment variable in order
> to point Docker to a `config.json` file in another location, so we
> have to fix the assumption we made about Docker.
> 
> We do not add this constant to stout, because it is not consistent
> across Windows applications. This particular logic is specific to the
> implementation of Docker. Other applications might check `$HOME` or
> `$HOMEPATH` on Windows.
> 
> 
> Diffs
> -----
> 
>   src/docker/docker.cpp 876dfffc2ee68e345ff336fefa6cf908c3d2a5c4 
> 
> 
> Diff: https://reviews.apache.org/r/65872/diff/1/
> 
> 
> Testing
> -------
> 
> Deployed a `docker.zip` consisting of `.docker/config.json` in "Linux-form" i.e. with
base64 encoded password (not `wincred`) using the following task:
> 
> ```
> {
>     "name": "fetcher-test",
>     "task_id": {"value" : "fetcher"},
>     "agent_id": {"value" : ""},
>     "resources": [
>         {
>             "name": "cpus",
>             "type": "SCALAR",
>             "scalar": {
>                 "value": 1
>             }
>         },
>         {
>             "name": "mem",
>             "type": "SCALAR",
>             "scalar": {
>                 "value": 512
>             }
>         }
>     ],
>     "command": {
>         "uris": [ {"value": "file://C:/Users/andschwa/docker.zip"} ],
>         "shell": false
>     },
>     "container": {
>         "type": "DOCKER",
>         "docker": {"image": "andschwa/nanoserver:1709"}
>     }
> }
> ```
> 
> The `andschwa/nanoserver:1709` is a _private_ repo, and `docker logout` was run (and
confirmed that the machine could not pull the image manually).
> 
> With this patch and the `docker.zip` URI, it was fetched, unzipped, and found by `docker
pull`, enabling it to successfully pull the private image.
> 
> ```
> > docker images
> REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
> andschwa/nanoserver   1709                816017814fa2        2 weeks ago         312MB
> ```
> 
> This is difficult to unit-test because it requires private credentials, an external private
docker repo, and global side effects of Docker images (i.e. you can't have it cached). But
I am, of course, open to ideas of how to programmatically test this.
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message