From 8a02e94fbf6741e249914ca2c9fcb19d38d4033d Mon Sep 17 00:00:00 2001 From: Stephen J Day Date: Mon, 28 Nov 2016 19:14:20 -0800 Subject: [PATCH] design: describe the role of the mount Signed-off-by: Stephen J Day --- design/mounts.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 design/mounts.md diff --git a/design/mounts.md b/design/mounts.md new file mode 100644 index 0000000..11e6462 --- /dev/null +++ b/design/mounts.md @@ -0,0 +1,32 @@ +# Mounts + +Mounts are the main interaction mechansim in containerD. Container systems of +the past typically end up having several disparate components independently +perform mounts, resulting in complex lifecycle management and buggy behavior +when coordinating large mount stacks. + +In containerD, we intend to keep mount syscalls isolated to the container +runtime component, opting to have various components produce a serialized +representation of the mount. This ensures that the mounts are performed as a +unit and unmounted as a unit. + +From an architecture perspective, components produce mounts and runtime +executors consume them. + +More imaginitive use cases include the ability to virtualize a series of mounts +from various components without ever having to create a runtime. This will aid +in testing and implementation of satellite components. + +## Structure + +The `Mount` type follows the structure of the historic mount syscall: + +| Field | Type | Description | +|-------|----|-------------| +| Type | `string` | Specific type of the mount, typically operating system specific | +| Target | `string` | Intended filesystem path for the mount destination. | +| Source | `string` | The object which originates the mount, typically a device or another filesystem path. | +| Options | `[]string` | Zero or more options to apply with the mount, possibly `=`-separated key value pairs. | + +We may want to further parameterize this to support mounts with various +helpers, such as `mount.fuse`, but this is out of scope, for now.