----------------------------------------------------------- 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 > >
