This is a temporary version for building
Fedora 25. Fedora 25 will be released during
code-freeze, and is currently in beta, so no
official images are available yet.
Current release date is scheduled for 2016-11-15
https://fedoraproject.org/wiki/Releases/25/Schedule
Once released, the image will be updated for
GA
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: c4f1cb779179b6145702174614706c462a5ceaae
Component: engine
Fixes#22564
When an error occurs on mount, there should not be any call later to
unmount. This can throw off refcounting in the underlying driver
unexpectedly.
Consider these two cases:
```
$ docker run -v foo:/bar busybox true
```
```
$ docker run -v foo:/bar -w /foo busybox true
```
In the first case, if mounting `foo` fails, the volume driver will not
get a call to unmount (this is the incorrect behavior).
In the second case, the volume driver will not get a call to unmount
(correct behavior).
This occurs because in the first case, `/bar` does not exist in the
container, and as such there is no call to `volume.Mount()` during the
`create` phase. It will error out during the `start` phase.
In the second case `/bar` is created before dealing with the volume
because of the `-w`. Because of this, when the volume is being setup
docker will try to copy the image path contents in the volume, in which
case it will attempt to mount the volume and fail. This happens during
the `create` phase. This makes it so the container will not be created
(or at least fully created) and the user gets the error on `create`
instead of `start`. The error handling is different in these two phases.
Changed to only send `unmount` if the volume is mounted.
While investigating the cause of the reported issue I found some odd
behavior in unmount calls so I've cleaned those up a bit here as well.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 9a2d0bc3adc0c21c82cd1974be45ea0449f9f224
Component: engine
This fix tries to address 27902 by adding a flag `--host`
to `docker service create` and `--host-add/--host-rm` to
`docker service update`, so that it is possible to
specify extra `host:ip` settings in `/etc/hosts`.
This fix adds `Hosts` in swarmkit's `ContainerSpec` so that it
is possible to specify extra hosts during service creation.
Related docs has been updated.
An integration test has been added.
This fix fixes 27902.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: ea9a23ccdbd3a861e4cfa3441482b448fd1c17a5
Component: engine
Changes to docs/reference/api/docker_remote_api_v1.25.md up to
and including 2d4203222574623b10d94817b9959a08698f516b
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
Upstream-commit: 48af987afe15a6bc3528a45b36c79448abbc8836
Component: engine
The ANSI escape codes \e[0A (cursor up 0 lines) and \e[0B (cursor down 0 lines)
are not well defined and are treated differently by different terminals. In
particular xterm treats 0 as a missing parameter and therefore defaults to 1,
whereas rxvt-unicode treats these escapes as a request to move 0 lines.
However the use of these codes is unnecessary and were really just hiding the
fact that we were not correctly computing diff when adding a new line. Having
added the new line to the ids map and output the corresponding \n we need to
then calculate a correct diff of 1 rather than leaving it as the default 0
(which xterm then interprets as 1). The fix is to pull the diff calculation out
of the else case and to always do it.
With this in place we can then avoid outputting escapes for moving 0 lines.
Actually diff should never be 0 to start with any more, but check to be safe.
This fixes corruption of `docker pull` seen with rxvt-unicode (and likely other
terminals in that family) seen in #28111. Tested with rxvt-unicode
($TERM=rxvt-unicode), xterm ($TERM=xterm), mlterm ($TERM=mlterm) and aterm
($TERM=kterm).
The test cases have been updated to match the new behaviour.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Upstream-commit: b08b437acc3bf52bd2c3435e632ed09f3312e489
Component: engine
- Neither swarm init or swarm update should take an unlock key
- Add an autolock flag to turn on autolock
- Make the necessary docker api changes
- Add SwarmGetUnlockKey API call and use it when turning on autolock
- Add swarm unlock-key subcommand
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 0f9fc54df9274327ed22f4e07f0981a648e0278a
Component: engine
Fixes two tests that tested containers restart policy without
actually having a restart policy
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: de1dad7074c84f56dd8f29bca0de29ba1e4ae6ce
Component: engine
Fixes a race condition in the kill tests where the container
would be killed but inspected before it's state changed. Fixes
this by waiting for a state change instead.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: ff42a1ab5348944c6d675575b00959b87b2c4032
Component: engine
Wire templating support of swarmkit for the engine, in order to be used
through services.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 6212ea669b4e92b3aa3985857f827ee9b95271fd
Component: engine
Sebastiaan van Stijn
Sebastiaan van Stijn
Vincent Demeester
Steve Durrheimer
Brian Goff
Andrea Luzzardi
allencloud
Yong Tang
Ben Firshman
Sandeep Bansal
msabansal
Tibor Vass
Andrew Hsu
Ian Campbell
Victor Vieux
Nishant Totla
Victor Vieux
erxian
Darren Stahl
Aaron Lehmann
Tonis Tiigi
Jana Radhakrishnan
Anusha Ragunathan
Christopher Jones
Santhosh Manohar