Merge pull request #361 from cpuguy83/stray_containerkit

Replace containerkit references with containerd
This commit is contained in:
Kenfe-Mickaël Laventure 2016-12-14 07:42:03 -08:00 committed by GitHub
commit 294d9d6ffa
3 changed files with 3 additions and 3 deletions

View file

@ -65,7 +65,7 @@ The table specifies whether or not the feature/component is in or out of scope.
| cow filesystem | Built in functionality for overlay, aufs, and other copy on write filesystems for containers | in | | | cow filesystem | Built in functionality for overlay, aufs, and other copy on write filesystems for containers | in | |
| distribution | Having the ability to push and pull images as well as operations on images as a first class api object | in | containerd will fully support the management and retrieval of images | | distribution | Having the ability to push and pull images as well as operations on images as a first class api object | in | containerd will fully support the management and retrieval of images |
| low-level networking drivers | Providing network functionality to containers along with configuring their network namespaces | in | Network support will be added via interface and network namespace operations, not service discovery and service abstractions. | | low-level networking drivers | Providing network functionality to containers along with configuring their network namespaces | in | Network support will be added via interface and network namespace operations, not service discovery and service abstractions. |
| build | Building images as a first class API | out | Build is a higher level tooling feature and can be implemented in many different ways on top of containerkit | | build | Building images as a first class API | out | Build is a higher level tooling feature and can be implemented in many different ways on top of containerd |
| volumes | Volume management for external data | out | The api supports mounts, binds, etc where all volumes type systems can be built on top of. | | volumes | Volume management for external data | out | The api supports mounts, binds, etc where all volumes type systems can be built on top of. |
| logging | Persisting container logs | out | Logging can be build on top of containerd because the containers STDIO will be provided to the clients and they can persist any way they see fit.,There is no io copying of container STDIO in containerd. | | logging | Persisting container logs | out | Logging can be build on top of containerd because the containers STDIO will be provided to the clients and they can persist any way they see fit.,There is no io copying of container STDIO in containerd. |

View file

@ -50,7 +50,7 @@ The runtime layer is responsible for the creation of containers and their manage
### Storage ### Storage
**Documents:** https://github.com/docker/containerkit/blob/master/design/snapshots.md **Documents:** https://github.com/docker/containerd/blob/master/design/snapshots.md
The current graph drivers were built when we only had overlay filesystems like aufs. The current graph drivers were built when we only had overlay filesystems like aufs.
We forced the model to be designed around overlay filesystems and this introduced a lot of complexity for snapshotting graph drivers like btrfs and devicemapper thin-p. We forced the model to be designed around overlay filesystems and this introduced a lot of complexity for snapshotting graph drivers like btrfs and devicemapper thin-p.

View file

@ -7,7 +7,7 @@ import (
"syscall" "syscall"
) )
// Mount is the lingua franca of the containerkit. A mount represents a // Mount is the lingua franca of containerd. A mount represents a
// serialized mount syscall. Components either emit or consume mounts. // serialized mount syscall. Components either emit or consume mounts.
type Mount struct { type Mount struct {
// Type specifies the host-specific of the mount. // Type specifies the host-specific of the mount.