vbatts
/
containerd
1
0
Fork 0
Code Pull Requests Releases Activity

Update roadmap on PR close policy for phases 

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This commit is contained in:
Michael Crosby 2016-12-12 13:13:52 -08:00
parent f651e60a3c
commit e61c869446
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
ROADMAP.md
View File

@ -9,6 +9,8 @@ The following are the different status the various phases of development can be
* Completed - the development work has been completed
* Stable - the apis for the phase are feature complete and considered stable
We would like to follow the roadmap and develop the components one by one to completion before starting the next phase. If PRs are opened for another phase before the previous phase has been completed they will be closed as we are not ready for them at that time.
## Phase 1
**Status:** In Progress
@ -42,14 +44,18 @@ This will also include moving the existing execution code support OCI's Runtime
**Status:** In Design
### Execution
### Runtime
The execution layer is responsible for the create of containers and the management and supervision of processes.
The runtime layer is responsible for the create of containers and the management and supervision of processes.
### Storage
**Documents:** https://github.com/docker/containerkit/blob/master/design/snapshots.md
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.
Our current approach is to model our storage layer after snapshotting drivers instead of overlay drivers as we can get the same results and its cleaner and more robust to have an overlay filesytem model snapshots than it is to have a snapshot filesystem model overlay filesystems.
## Phase 3
Phase 3 involves porting the network drivers from libnetwork and finding a good middle ground between the abstractions of libnetwork and the CNI spec.