docs/spec: Proposal for generic content distribution manifest #993
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A proposal for the V2 schema version 2 manifest format, designed for generic content addressability and with an example for how this addresses multi-architecture support in the distribution registry. Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
|
Related and valuable discussion on what brought about this particular design:
|
| "target": { | ||
| "mediaType": "application/vnd.docker.container.image.v2", | ||
| "size": 7023, | ||
| "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7" |
There was a problem hiding this comment.
What is this pointing to in the multi-arch case?
There was a problem hiding this comment.
@aaronlehmann I think the architecture should be specified in the labels here. Typically, I would expect this to be pointed at an image.Image json structure.
There was a problem hiding this comment.
Another possibility is that this is pointing at a fat manifest, which would be separate format (Or we use dependencies to identify the fat manifest, as is done in the example).
|
cc @vbatts |
|
cc @mattmoor |
|
@stevvooe I don't want to hijack this discussion, so if there is a better venue for this discussion please advise. A consideration in this switch is that it will make is progressively more difficult to serve the v1 API from the v2 format (for old clients pulling new images, e.g. ubuntu). As DockerHub is clearly providing such a compatibility layer today, can this switch reasonably be made before DockerHub turns down v1 support? What is the plan to roll out this breaking change to clients? My expectation of breaking API changes is that they are done on top of a fresh revision of the API e.g. Also (unrelated), in the example the v1 json is under thanks. |
|
@mattmoor Backwards compatibility is definitely a consideration. The goal right now is to clearly identify and define the target format for v2. Once this target is clear, this format can easily be converted into a v1/v2 manifest at request time. Let's get the format defined then we can select a strategy for backwards compatibility. |
|
@stevvooe SGTM |
| "size": 7023, | ||
| "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7" | ||
| }, | ||
| "dependencies": [ |
There was a problem hiding this comment.
Is this dependencies list intended to be ordered or will the order be defined by the target?
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 5, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 5, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
|
Closing in favor of #1068 |
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 14, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 14, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 14, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 14, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 14, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Oct 16, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Dec 18, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Dec 18, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Dec 18, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
added a commit
to aaronlehmann/distribution
that referenced
this pull request
Dec 18, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
BrianBland
pushed a commit
to BrianBland/distribution
that referenced
this pull request
Dec 28, 2015
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
BrianBland
pushed a commit
to BrianBland/distribution
that referenced
this pull request
Jan 6, 2016
This is a follow-on to PR distribution#62, and it borrows much of the format from distribution#993, but uses specific formats for the image manifest and manifest list (fat manifest) instead of a combined generic format. The intent of this proposed manifest format is to allow multi-arch, and allow for full content-addressability of images in the Docker engine. Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A proposal for the V2 schema version 2 manifest format, designed for
generic content addressability and with an example for how this
addresses multi-architecture support in the distribution registry.
This is a follow-on to PR #62 as requested by the distribution team to
get the discussion going again and move forward on an agreed-to
v2.2 specification.
Docker-DCO-1.1-Signed-off-by: Phil Estes estesp@linux.vnet.ibm.com (github: estesp)