When starting up a snapshot driver on subsequent runs, the
mkdir call will return an exist error, this can be safely
ignored.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Previously hardlinking to an unmodified file or linking to a file
which was touched by not detected as modified caused a new file
to be created on unpack. This new file and the original source file
were not linked since no link record was created in the tar. This
change addresses this by adding links for all hardlinks to a file
when it is detected as changed. These links will be written after
the source file is written and may occur out of order in regard to
file name.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Touching the file before hardlinking was covering up a bug in
how hard links are handled in tar. Without the touch the hardlink
should still be included and both files should hardlink after
the tar is applied.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
when wanting to craft a custom config, but based on the default config,
add a route to output the containerd config to a tempfile.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
With this changeset, image store access is now moved to completely
accessible over GRPC. No clients manipulate the image store database
directly and the GRPC client is fully featured. The metadata database is
now managed by the daemon and access coordinated via services.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Server and Client images of the image store are now provided. We have
created an image metadata interface and converted the bolt functions to
implement that interface over an transaction. A remote client
implementation is provided that implements the same interface.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This is a first pass at the metadata required for supporting an image
store. We use a shallow approach to the problem, allowing this
component to centralize the naming. Resources for this image can then be
"snowballed" in for actual implementations. This is better understood
through example.
Let's take pull. One could register the name "docker.io/stevvooe/foo" as
pointing at a particular digest. When instructed to pull or fetch, the
system will notice that no components of that image are present locally.
It can then recursively resolve the resources for that image and fetch
them into the content store. Next time the instruction is issued, the
content will be present so no action will be taken.
Another example is preparing the rootfs. The requirements for a rootfs
can be resolved from a name. These "diff ids" will then be compared with
what is available in the snapshot manager. Any parts of the rootfs, such
as a layer, that isn't available in the snapshotter can be unpacked.
Once this process is satisified, the image will be runnable as a
container.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This adds very simple deletion of images by name. We still need to
consider the approach to handling image name, so this may change. For
the time being, it allows one to delete an image entry in the metadata
database.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
