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>
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>
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>
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)
Properly CloseWrite() the client socket once done with stdin when using
TLS connection (this used to rely on an erroneous type assertion).
Fixes#8658.
Fixes#8642.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Signed-off-by: Michael Crosby <crosby.michael@gmail.com>
Sometimes other programs can bind on ports from our range, so we just
skip this ports on allocation.
Fixes#9293
Probably fixes#8714
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Prior to this patch, one would get the output of docker inspect xxx
as below:
user@server:/mnt$ docker inspect ubuntu
[{
"Architecture": "amd64",
...
"VirtualSize": 199257566
}
]user@server:/mnt$
The last ']' was on the same line with the prompt, i wonder if it is
really what we want it be, it is a little weird, so i add a '\n' to it.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Updated the documentation to cover the installation of Docker on
openSUSE and on SUSE Linux Enterprise.
Docker-DCO-1.1-Signed-off-by: Flavio Castelli <fcastelli@suse.com> (github: flavio)
The documentation for EXPOSE seems to indicate, that EXPOSE is only relevant in
the context of links, which is not the case.
Signed-off-by: Jacob Atzen <jatzen@gmail.com>
Vivek Goyal