Prevents having multiple database connections open to a connection,
preventing bugs with locking by relying on the boltdb database
object to handle synchronization rather than file locking.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Adds back links from parent to children in order to prevent
deletion of a referenced snapshot in a namespace.
Avoid removing snapshot during metadata delete to
prevent shared namespaces from being mistakenly deleted.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Files/folders deleted in lower layer and commited,
it should not reflect on upper layer
Signed-off-by: Kunal Kushwaha <kushwaha_kunal_v7@lab.ntt.co.jp>
The basic test does an assert on the existing snapshots.
Update the check just to assert the expected snapshots were
found during the walk.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
The testsuite alters global state by setting the umask, avoid
running the testsuite in parallel and move umask manipulation
to the test suite level to individual tests may run in parallel.
Added better error messaging and handling.
Removed reliance on testing object for handling cleanup failure.
When a cleanup error occurred, it would fail the test but the log
would get skipped. With this change the failure will show up for
the running test.
Update test unmounting to set the detach flag, avoiding races with
btrfs which may see the device as busy when attempting to unmount.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Previously "`/`" in a container was always owned by `root:root` (0/0), even if
`withRemappedSnapshot` had been used. Meaning that if `withUserNamespace` is
used then `/` can be remapped to `nobody:nogroup` (65534/65534).
The fix is is twofold:
- incrementFS should operate on the root of the tree.
- when creating a new snapshot we must propagate the ownership of the topmost
"lower" directory into the new "upper".
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Update snapshot storage to use boltdb keys instead of protobuf.
Add update function to snapshotter to allow updating labels.
Add option type for creating snapshots to allow setting labels.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
The snapshot test suite is designed to run against the snapshotter
interface, run the test suite for metadata and client implementations
of the snapshotter interface.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
What started out as a simple PR to remove the "Readonly" column became an
adventure to add a proper type for a "View" snapshot. The short story here is
that we now get the following output:
```
$ sudo ctr snapshot ls
ID PARENT KIND
sha256:08c2295a7fa5c220b0f60c994362d290429ad92f6e0235509db91582809442f3 Committed
testing4 sha256:08c2295a7fa5c220b0f60c994362d290429ad92f6e0235509db91582809442f3 Active
```
In pursuing this output, it was found that the idea of having "readonly" as an
attribute on all snapshots was redundant. For committed, they are always
readonly, as they are not accessible without an active snapshot. For active
snapshots that were views, we'd have to check the type before interpreting
"readonly". With this PR, this is baked fully into the kind of snapshot. When
`Snapshotter.View` is called, the kind of snapshot is `KindView`, and the
storage system reflects this end to end.
Unfortunately, this will break existing users. There is no migration, so they
will have to wipe `/var/lib/containerd` and recreate everything. However, this
is deemed worthwhile at this point, as we won't have to judge validity of the
"Readonly" field when new snapshot types are added.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
We may want to create this as a subvolume if the parent is btrfs
or support mounting on load in the future.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
The "nextnext" snapshot is being removed at the end of the function.
So umount is needed before removing the snapshot.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Now that we have most of the services required for use with containerd,
it was found that common patterns were used throughout services. By
defining a central `errdefs` package, we ensure that services will map
errors to and from grpc consistently and cleanly. One can decorate an
error with as much context as necessary, using `pkg/errors` and still
have the error mapped correctly via grpc.
We make a few sacrifices. At this point, the common errors we use across
the repository all map directly to grpc error codes. While this seems
positively crazy, it actually works out quite well. The error conditions
that were specific weren't super necessary and the ones that were
necessary now simply have better context information. We lose the
ability to add new codes, but this constraint may not be a bad thing.
Effectively, as long as one uses the errors defined in `errdefs`, the
error class will be mapped correctly across the grpc boundary and
everything will be good. If you don't use those definitions, the error
maps to "unknown" and the error message is preserved.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
