Currently devicemapper backend does not keep track of used device Ids in
the pool. It tries a device Id and if that device Id exists in pool, it
tries with a different Id and keeps on doing this in a loop till it succeeds.
This worked fine so far but now we are moving to transaction based
device creation and deletion. We will keep deviceId information in
transaction which will be rolled back if docker crashed before transaction
was complete.
If we store a deviceId in transaction and later figure out it already
existed in pool and docker crashed, then we will rollback and remove
that existing device Id from pool (which we should not have).
That means, we should know free device Id in pool in advance before
we put that device Id in transaction.
Hence this patch creates a bitmap (one bit each for a deviceId), and
sets the bit if device Id is used otherwise resets it. This patch
is just preparing the ground right now. Actual usage will follow
in later patches.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 4d39e056aac2fadffcb8560101f3c31a2b7db3ae
Component: engine
Right now setupBaseImage() uses deleteDevice() to delete uninitialized
base image while rest of the code uses DeleteDevice(). Change it and
use a common function everywhere for the sake of uniformity.
I can't see what harm can be done by doing little extra locking done
by DeleteDevice().
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 359a38b26a164f430c79fe542babb77c6e48dcc3
Component: engine
Very soon we will have the notion of an open transaction and keep its
details in a metafile.
When a new transaction is opened, we allocate a new transaction Id,
do the device creation/deletion and then we will close the transaction.
I thought that OpenTransactionId better represents the semantics of
transaction Id associated with an open transaction instead of NewtransactionId.
This patch just does the renaming. No functionality change.
I have also introduced a structure "Transaction" which will keep all
the details associated with a transaction. Later patches will add more
fields in this structure.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: f078bcd8e50913fd8b05022ebd047c5a1f2e3d52
Component: engine
Currently new transaction Id is created using allocateTransactionId()
function. This function takes NewTransactionId and bumps up by one
to create NewTransactionId.
I think ideally we should be bumping up devices.TransactionId by 1
to come up with NewTransactionId. Because idea is that devices.TransactionId
contains the current pool transaction Id and to come up with a new
transaction Id bump it up by one.
Current code is not wrong as we are keeping NewTransactionId and
TransactionId in sync. But it will be more direct if we look at
devices.TransactionId to come up with NewTransactionId. That way
we don't have to even initialize NewTransactionId during startup
as first time somebody wants to do a transaction, it will be
allocated fresh.
So simplify the code a bit. No functionality change.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 7b0a1b814b8f13e30df466dd66c3fdc2114eac28
Component: engine
Currently updatePoolTransactionId() checks if NewTransactionId and
TransactionId are not same only then update the transaction Id in pool. This
check is redundant. Currently we call updatePoolTransactionId() only from
two places and both of these first allocate a new transaction Id.
Also updatePoolTransactionId() should only be called after allocating
new transaction Id otherwise it does not make any sense.
Remove the redundant check and reduce confusion.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 6d347aeb6984ebdcb1051212ab3103880ef69ab0
Component: engine
Create two new helper functions for device and snap device creation. These
functions will not only create the device and also register the device.
Again, makes the code structure better and keeps all transaction logic
contained to functions instead of spilling over into functions like
setupBaseImage or AddDevice().
Just the code reorganization. No functionality change.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: ad9118c696c0953ec48eec15ea4b7546296d7c20
Component: engine
Currently registerDevice() adds a device to in-memory table, saves metadata
and also updates the pool transaction ID.
Now move transaciton Id update out of registerDevice() and provide a new
function unregisterDevice() which does the reverse of registerDevice().
This will simplify some code down the line and make it more structured.
This is just code reorganization and should not change functionality.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 442247927b8e6c102ce1f94de58c7f93aab3d271
Component: engine
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>
Upstream-commit: 7b2b15d3e9f9b7ad898a36bbe5ceb42c9ca58d47
Component: engine
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>
Upstream-commit: 5be77901cd505aad002b912b5febe2ba6baa23fd
Component: engine
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>
Upstream-commit: 824a87f7efb94e4f307d920c3c3689156d6e633f
Component: engine
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>
Upstream-commit: 0db6cc85edfccb16ce5308eea767530e1a3f6906
Component: engine
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>
Upstream-commit: 004d8b9b337f4a6cf68c124e89e02e673c6320fc
Component: engine
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>
Upstream-commit: b721d6d8d0313fbb4b80e12318c96fc4004ee96b
Component: engine
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>
Upstream-commit: bb00453e58a86b9787ac4b3e7df3c48d8ddc3f87
Component: engine
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)
Upstream-commit: 8d9e25dbddc189f4094e0f25a90f2b8a25deec9d
Component: engine
The `Engine.Logf` method was unused and confusing.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 59da197de8f040eed7560747476f97ce8afad293
Component: engine
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>
Upstream-commit: e98e56bb1edc3835bc835c9e034780845c64d797
Component: engine
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>
Upstream-commit: a00a1a1fca020d21cb677439160e018bda5c3835
Component: engine
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>
Upstream-commit: 921346be48d20a66b2b5763144b064395285bb32
Component: engine
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)
Upstream-commit: 47d8ec0a42ce2cd71a0275665f2e7d74a5a56cbf
Component: engine
