When sending a bad URL in the fromSrc parameter using cURL
the response will have status code 200 while it should have 404
or 500 (depends on the error).
This commit addresses this problem in the following ways:
* Before, `src` was parsed using url.Parse and if the
returned `url.Scheme` was empty it was set to 'http'
and `url.Host` was set to `src`.
This is bad because if `src` was 'web.com/tars/image1.tar'
The `url.String()` returns 'web.com%2Ftars%2Fimage1.tar`
which will cause the daemon to fail downloading the file
* Before writing the "Downloading" message, the image
is attempted to be downloaded and if there is no error
the "Downloading" message is sent.
Signed-off-by: Boaz Shuster <ripcurld.github@gmail.com>
Remove forked reference package. Use normalized named values
everywhere and familiar functions to convert back to familiar
strings for UX and storage compatibility.
Enforce that the source repository in the distribution metadata
is always a normalized string, ignore invalid values which are not.
Update distribution tests to use normalized values.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
This fix tries to fix the issue raised in 21845. The issue with 21845
is that if multiple `--volumes-from` with the same destination has been
specified, then one volume will be overridden by the other. This will mess
up with volumes reference and prevent the overridden volume from
being removed at the end.
Issue 21845 was observed with `docker-compose` though it is possible to
emulate the same behavior with `docker` alone:
```
$ cat Dockerfile
FROM busybox
VOLUME ["/tmp/data"]
$ docker build -t vimage .
$ docker run --name=data1 vimage true
$ docker run --name=data2 vimage true
$ docker run --name=app --volumes-from=data1 --volumes-from=data2 -d busybox top
$ docker rm -f -v $(docker ps -aq)
$ docker volume ls
$ docker volume rm ...
```
NOTE: Second case:
```
$ cat Dockerfile
FROM busybox
VOLUME ["/tmp/data"]
$ docker build -t vimage .
$ docker run --name=data1 vimage true
$ docker run --name=data2 vimage true
$ docker run --name=app --volumes-from=data1 --volumes-from=data2 -v /tmp/data:/tmp/data -d busybox top
$ docker rm -f -v $(docker ps -aq)
$ docker volume ls
$ docker volume rm ...
```
NOTE: Third case: Combination of --volumes-from and `HostConfig.Mounts` (API only)
This fix tries to address the issue by return an error if duplicate
mount points was used with `--volumes-from`.
An integration test has been added.
This fix fixes 21845.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
- libnetwork controller Networks() already returns
a copy list. Also Networks() correctly skips any
network which ahs already been marked for deletion
while getNetworks implementation bypass this.
Signed-off-by: Alessandro Boch <aboch@docker.com>
Fixes manpages for p and z by downloading a specific version
of go instead of relying on the distro version.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
While it is important to not create controllers for an invalid task,
certain properties should only be checked immediately before use. Early
host validation of mounts prevents resolution of the task Executor when
the mounts are not relevant to execution flow. In this case, we have a
check for the existence of a bind mount path in a creation function that
prevents a task controller from being resolved. Such early validation
prevents one from interacting directly with a controller and result in
unnecessary error reporting.
In accordance with the above, we move the validation of the existence of
host bind mount paths to the `Controller.Start` phase. We also call
these "checks", as they are valid mounts but reference non-existent
paths.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
