Initialize volumes when container is created
Fixes #8942
Current behavior is that volumes aren't initialized until start.
Volumes still need to be initialized on start since VolumesFrom and
Binds can be passed in as part of HostConfig on start, however anything
that's already been initialized will just be skipped as is the current
behavior.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
refer to the registry instead of the hub

Signed-off-by: Jeff Anderson <jeff@docker.com>
Fix dead link in oracle.md
Fix dead link cli.md
Rename overlayfs to overlay

Since Linux 3.18-rc6, overlayfs has been renamed overlay.

This change was introduced by the following commit in linux.git:
ef94b1864d1ed5be54376404bb23d22ed0481feb ovl: rename filesystem type to "overlay"

Signed-off-by: Lénaïc Huard <lhuard@amadeus.com>
graphdb: initialize the database semi-idempotently on every connection.

Docker-DCO-1.1-Signed-off-by: Erik Hollensbe <github@hollensbe.org> (github: erikh)
Update dockerimages.md

remove 'public registry'

Signed-off-by: Jeff Anderson <jeff@docker.com>
Remove unused Engine.Logf

The `Engine.Logf` method was unused and confusing.

Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Merge pull request #9457 from icecrime/engine_logf

Remove unused Engine.Logf method
Webhooks documentation: second pass addressing @fredlf's comments

Signed-off-by: Joffrey F <joffrey@docker.com>
Merge pull request #9273 from programmerq/dockerimages_hub

refer to the registry instead of the hub
Merge pull request #9460 from shin-/docs_webhooks2

Webhooks documentation: additional improvements
Fix TarSum iteration test

I noticed that 3 of the tarsum test cases had expected a tarsum with
a sha256 hash of
  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
As I've been working with sha256 quite a bit lately, it struck me that
this is the initial digest value for sha256, which means that no data
was processed. However, these tests *do* process data. It turns out that
there was a bug in the test handling code which did not wait for tarsum
to end completely. This patch corrects these test cases.

I'm unaware of anywhere else in the code base where this would be an issue,
though we definitily need to look out in the future to ensure we are
completing tarsum reads (waiting for EOF).

Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Merge pull request #9463 from jlhawn/tarsum_test_fix

Fix TarSum iteration test
Merge pull request #9430 from sindhus/patch-3

Fix dead link cli.md
Merge pull request #9429 from sindhus/patch-1

Fix dead link in oracle.md
Rename the overlay storage driver

so that docker is started with `docker -d -s overlay` instead of `docker -d -s overlayfs`

Signed-off-by: Lénaïc Huard <lhuard@amadeus.com>
Remove the last references to overlayfs

This only renames docker internal structures.
It has no impact on the end-user.

Signed-off-by: Lénaïc Huard <lhuard@amadeus.com>
Merge pull request #9426 from lhuard1A/overlay_rename

Rename overlayfs to overlay
Fix invalid argument error on push

With 32ba6ab from #9261, TempArchive now closes the underlying file and
cleans it up as soon as the file's contents have been read. When pushing
an image, PushImageLayerRegistry attempts to call Close() on the layer,
which is a TempArchive that has already been closed. In this situation,
Close() returns an "invalid argument" error.

Add a Close method to TempArchive that does a no-op if the underlying
file has already been closed.

Signed-off-by: Andy Goldstein <agoldste@redhat.com>