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>
contrib: fix the docker-device-tool

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
pkg/tarsum: specification on TarSum checksum

Signed-off-by: Vincent Batts <vbatts@redhat.com>
pkg/tarsum: review amendments

(separate commit to preserve github conversation)

Signed-off-by: Vincent Batts <vbatts@redhat.com>
pkg/tarsum: review cleanup

Signed-off-by: Vincent Batts <vbatts@redhat.com>
tarsum: updates for jamtur01 comments

Signed-off-by: Vincent Batts <vbatts@redhat.com>
graphdb: initialize the database semi-idempotently on every connection.

Docker-DCO-1.1-Signed-off-by: Erik Hollensbe <github@hollensbe.org> (github: erikh)
Man: describe --icc option better

Current description is misleading. It make an impression the --icc=false
prevents containers to talk with each other.

Signed-off-by: Michal Minar <miminar@redhat.com>

Docker-DCO-1.1-Signed-off-by: Michal Minar <miminar@redhat.com> (github: SvenDowideit)
Man: describe storage options

Documented --storage-opt=[] option in man page. Content taken from:

  daemon/graphdriver/devmapper/README.md

Signed-off-by: Michal Minar <miminar@redhat.com>

Docker-DCO-1.1-Signed-off-by: Michal Minar <miminar@redhat.com> (github: SvenDowideit)
Doc: described storage-driver options in cli reference

Documented --storage-opt=[] option in cli reference page. Content taken
from:

  daemon/graphdriver/devmapper/README.md

Signed-off-by: Michal Minar <miminar@redhat.com>

Docker-DCO-1.1-Signed-off-by: Michal Minar <miminar@redhat.com> (github: SvenDowideit)
80-char limit

Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>

Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (github: SvenDowideit)
Try out a different phrase for --icc

Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>

Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (github: SvenDowideit)
fixes as per feedback

Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>

Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (github: SvenDowideit)
devmapper: Do not check for pool transaction id during old metadata migration

Current code is associating a transaction id with each device and if pool
transaction id is greater that value, then current code assumes that device
is there in pool.

Transaction id of pool is a mechanism so that during device creation and
removal one can define a transaction and during startup figure out if
transaction was complete or not. I think we are using transaction id 
throughout the code little inappropriately.

For example, if a device is being deleted, it is possible that we deleted
the device from pool but before we could delete metafile docker crashed.
When docker comes back it will think that device is in the pool (due to
device transaction id being less than pool transaction id) but device
is not in the pool.

Similary, it could happen that some data in the pool is corrupted and
during pool repair some devices are lost (without docker knowing about
it). In that case tool pool transaction id will be higher than device
transaction id and there are no guaratees that device is actually in
the pool.

So move away from this model where we think that a device is in pool if pool
transaction id is greater than device transaction Id. Per device
transaction Id just says that after device creation this should be pool's
transaction Id and nothing more.

Transaction id is per pool property (as opposed to per device property) and
will be used internally to figure out if last transaction was complete or
not and recover from failure during docker startup.  

If for some reason metafile is present but device is not in pool, then 
device activation will fail later.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Do not check for transaction id during device metadata loading

Again, just because device transaction id is greater than pool transaction
id, it does not guarantee that device is in the pool. So do not check
of this during loading of device metadata.

Docker needs to deal with it. And device activation will fail when we try
to activate a device for whom metafile is present but there is no device
in the pool.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Remove unnecessary call to allocateTransactionId() during device removal

Remove call to allocateTransactionId() during device removal. This seems to
be unnecessary and it is not clear what this call is doing.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Remove transaction Id update from saveMetaData()

Right now saveMetaData() is kind of little overloaded function. It is
supposed to save file metadata to disk. But in addition if user has
bumped up NewTransactionId before calling saveMetaData(), then it will
also update the transaction ID in pool.

Keep saveMetaData() simple and let it just save the file. Any update
of pool transaction ID is done inline in the code which needs it.

Also create an helper function updatePoolTransactionId() to update pool
transaction Id.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Move pool id query and migration of old data in separate function

Right now initMetaData() first queries the pool for current transaciton Id
and then it migrates the old metafile.

Move pool transaction Id query and file migration in separate functions
for better code reuse and organization.

Given we have removed device transaction Id dependency from saveMetaData(),
we don't have to query pool transaction Id before migrating files.
 
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Do not add back device into hash map if meta file removal failed

When we are deleting a device, we also delete associated metadata file. If
that file removal fails, we are adding back the device in in-memory
table. I really can't see what's the point. When next lookup takes place
it will be automatically loaded if need be. Remove that code.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
devmapper: Use device id as specified by caller

Currently devicemapper CreateDevice and CreateSnapDevice keep on retrying
device creation till a suitable device id is found. 

With new transaction mechanism we need to store device id in transaction
before it has been created.

So change the logic in such a way that caller decides the devices Id to
use. If that device Id is not available, caller bumps up the device Id
and retries.

That way caller can update transaciton too when it tries a new Id. Transaction
related patches will come later in the series.
  
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>