You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replace Moby image backend with containerd. This will move ownership of image related code outside of Moby allowing for a large code and scope reduction in Moby. Many refactorings can be done before doing the switch, but changing the backend can only be done in large increments due to the metadata storage architecture difference in containerd.
Overview
Image storage moved to containerd metadata database
Migration of existing metadata
All image requests use containerd client
Distribution code removed and replaced with containerd client
Containerd’s snapshotters supported
Graph drivers scoped down (no more mounting/diffing)
Graph drivers supported as containerd snapshotter plugins
Plan
This change is deep, in some cases we can completely bypass existing packages and use containerd (i.e. distribution), while in others we will need to write new code to integrate with existing Docker interfaces. There will likely be a few large PRs since Docker will not be able to be in a functional state unless the data storage is consistently used by all commands. This plan is an attempt to break down the work in individual PRs which can be merged in isolation while preserving as much functionality as possible. Some PRs may temporarily break upgrades since we will want to begin testing and integrating with some of these changes before the upgrade migration code is complete.
I have broken this down into phases to better understand the relationship between work items. There is no definition for the end of a phase but rather the work in each phase should be able to be completed concurrently.
Phase 1
libcontainerd simplification and windows runtime integration
daemon updates
replace plugin executor interface with containerd client
replace image backend and distribution with containerd client
includes all image operations: ls, rm, pull, push, etc
unpack from content store into layer store
minimizing graph driver scope
move mount to layer store and utilize containerd mount package
move diff to layer store and utilize containerd diff packages
Phase 2
move libcontainerd into daemon
image metadata migration
support migrating existing docker metadata into containerd metadata store
graph drivers updated to snapshotter interface
layer store communicating with containerd snapshotter
Phase 3
replace layer store with snapshotter
graph drivers exposed as containerd snapshotter plugins
support layer recreation into content store from tar split on push
update storage driver configuration to reflect snapshotter preference
Can we also allow specifying snapshotted per container, as in ctr run --snapshot?
Yes, but out of scope for this proposal. I am not proposing any new functionality as part of this proposal, but this proposal does make many new functionality possible.
Are we ready to drop schema1 push? I'm not sure Quay supports schemae2/OCIv1 yet.
Yes and also not sure. They have already already indicated they are working on it, we can make sure they are kept aware of the timeline here, but that discussion is happening in another issue.
I propose we move the state of this issue from "proposal" to "yes we're doing this thing" if we have enough buy-in that this is for sure. (I think this is a desirable thing to do)
Reacted by Justin Cormack, atomi, carl-fredrik grimberg and Helio Machado
@andrewhsu@dmcgowan cc: @ajeetraina@dbjpanda
Hi, I’m Ryo Nakao, a student from Japan. I’m interested in this issue as a project idea of Google Summer of Code 2019. So I have two questions:
Is it alright that discussing about this idea here?
Where should I share the Google doc link once drafting is completed?
Activity
AkihiroSuda commentedon Oct 16, 2018
ctr run --snapshot?dmcgowan commentedon Oct 16, 2018
Yes, but out of scope for this proposal. I am not proposing any new functionality as part of this proposal, but this proposal does make many new functionality possible.
Yes and also not sure. They have already already indicated they are working on it, we can make sure they are kept aware of the timeline here, but that discussion is happening in another issue.
andrewhsu commentedon Oct 25, 2018
I propose we move the state of this issue from "proposal" to "yes we're doing this thing" if we have enough buy-in that this is for sure. (I think this is a desirable thing to do)
nakabonne commentedon Feb 27, 2019
@andrewhsu @dmcgowan cc: @ajeetraina @dbjpanda
Hi, I’m Ryo Nakao, a student from Japan. I’m interested in this issue as a project idea of Google Summer of Code 2019. So I have two questions:
nakabonne commentedon Feb 27, 2019
I heard that Docker withdrew the application earlier. I'm planning to contribute after the GSoC period is over, so thank you.
alyiox commentedon Aug 21, 2023
It seems that this issue or feature is pending now?
AkihiroSuda commentedon Aug 21, 2023
Experimentally implemented in v24:
moby/daemon/daemon.go
Line 825 in cf15460
Remaining issues are tracked in containerd-integrationIssues and PRs related to containerd integration