Updated Windows installation documentation with newest
screencasts and Chocolatey instructions to install windows
client CLI.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Upstream-commit: 2b320a230979c3222162567b9d1d3193b0806cd5
Component: engine
registry/SearchResults was missing the "is_automated" field.
I added it back in.
Pull this 'table' removal one from the others because it fixed
a bug too
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 67b4cce0f6c835cf9e53313a026af2e825ba8b10
Component: engine
If docker search with --starts=${negative number}, it would show the war...
Upstream-commit: 2c5da7d1accdc9a2be321602285946bbe29593c2
Component: engine
* when no containers are returned, go test would then aborts with:
panic: runtime error: index out of range
Signed-off-by: Todd Whiteman <todd.whiteman@joyent.com>
Upstream-commit: 3e51a8147510fb59d6206fe7310feaebc2d69fbc
Component: engine
Right now we try device removal at the interval of 10ms and keep on trying
till either device is removed or 10 seconds are over. That means if device
is busy, we will try 1000 times in those 10 seconds.
Sounds too high a frequency of deivce removal retrial. All the logs are
filled easily. I think it is a good idea to slow down a bit and retry at
the interval of 100ms instead of 10ms.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: c737800b7faced4b53854c8cb6766ebe58a3c3e9
Component: engine
During device removal, we are first waiting for device to close() in a tight
loop for 10 seconds. I am not sure why do we need it. First of all we come
here once the umount() is successful so device should be free. For some reason
of device is temporarily busy, then removeDevice() logic retries device removal
logic in a loop for 10 seconds and that should cover it. Can't see why one
more 10 seoncds loop is required before attempting device removal.
One loop should be able to cover all the temporary device busy conditions and
if condition is not temporary then 10 seconds loop is not going to help anyway.
So instead of two loops of 10 seconds each, I am converting it to a single
loop of 20 seconds. May be 10 second loop is good enough but for now I am
keeping it 20 seconds to avoid any regressions.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: f74d12012c21349b2bd51d9c395a99331ff0a9a5
Component: engine
Currently in device removal path (device deactivation), we wait
for 10 seconds for devive to actually go away. waitRemove().
In current code this is not required. If dm removal task has completed
and one has done the wait on udev cookie, then device is gone and there
is no need to write another loop to wait for device removal.
This patch removes the waitRemove() which waits for 10 seconds after
device removal. This seems unnecessary.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: dbf04ec4e2a6b4fe73f7f300918a906c0ff1a37b
Component: engine
UdevWait() is deferred and takes uint cookie as an argument. As arguments
to deferred functions are calculated at the time of call, it is possible
that any update to cookie later by libdm are not taken into account when
UdevWait() is called. Hence use a pointer to uint as argument to UdevWait()
function.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 665656afbb8932a11c69c0cd79e21a768aa46d38
Component: engine
devmapper graph driver retries device removal 1000 times in case of failure
and if this fills up console with 1000 messages (when daemon is running in
debug mode). So remove these debug messages.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: cb7c893275c32ddfa775c3f22869a9c211024c71
Component: engine
There are issues with libdm logging. Right now if docker daemon is run
in debug mode, logging by libdm is too verbose. And if a device can't
be removed, thousands of messages fill the console and one can not see
what's going on.
This patch removes devicemapper.LogInitVerbose() call as that call will
only work if docker was not registering its own log handler with libdm.
For some reason docker registers one with libdm and libdm hands over
all the messages to docker (including debug ones). And now it is up to
devmapper backend to figure out which ones should go to console and
which ones should not.
So by default log only fatal messages from libdm. One can easily modify
the code to change it for debugging purposes.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: e07d3cd9acf14219f33e12375fb8c2e3fe02ad0c
Component: engine
Always stop the test daemon in an attempt to fix race conditions in
subsequent tests.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 02c2308e39930677a7f4bb7f4215331a4d87566f
Component: engine
moxiegirl
Jessie Frazelle
Ahmet Alp Balkan
Doug Davis
Michael Crosby
Antonio Murdaca
Huu Nguyen
Arnaud Porterie
Alexander Morozov
Doug Davis
Aaron Welch
eluck
Jamie Hannaford
Tianon Gravi
Simei He
Joey Gibson
Yuan Sun
Tibor Vass
Phil Estes
Todd Whiteman
Michael Crosby
Vivek Goyal
unclejack