distribution: Reword scope table to avoid repository/image distinction #46
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
wking
force-pushed
the
image-repository-wording
branch
from
bb4908e to
8dd6a19
Compare
Closed
wking
force-pushed
the
image-repository-wording
branch
2 times, most recently
from
d00d12a to
c2f052d
Compare
Contributor
Author
|
ping @caniszczyk, now that @mikebrow and I are on the same page ;). |
jonjohnsonjr
suggested changes
Mar 1, 2018
proposals/distribution.md
Outdated
| Docker's registery API already provides endpoints for fetching manifest objects by digest][get-manifest]. | ||
| Docker's registery API does not currently provide endpoints for fetching image objects by digest, but this is the project where that will happen. | ||
| * “Retrieving image content by its content-addressable hash”. | ||
| Docker's registery API already provides [endpoints for fetching manifest objects by digest][get-manifest]. |
Contributor
There was a problem hiding this comment.
Nit: s/registery/registry/ here and below.
Contributor
Author
proposals/distribution.md
Outdated
| Other tag-listing endpoints needed for backwards-compatibility are therefore in scope as well. | ||
|
|
||
| Repository actions and listing images within a repository are considered part of distribution policy or content management and are out of scope for this entry's per-image action. | ||
| Grouping image indexes in repositories is considered part of distribution policy or content management and are out of scope for this entry's per-image action. |
Contributor
There was a problem hiding this comment.
Nit: "Grouping image indexes ... is out of scope..."
or even:
"...is considered part of distribution policy or content management, which are out of scope..."
Contributor
Author
Mike and I have had a lengthy discussion before realizing that we were not interpreting these terms the same way [1]. This commit replaces some explicit object-type lists with "objects defined in the image specification", which is more concrete than using terms without local definitions. I've also added image-spec links where I do use object-type terms. And I've used the wordy but more explicit "groups of image indexes" instead of "repositories" in most cases. I've also explicitly listed /v2/_catalog as out of scope. It's a higher-level endpoint than the image-spec objects. As Patrick [2] and Stephen [3] pointed out when the endpoint landed, it's for internal administration. Matt suggested keeping it out of the user-facing API on those grounds [4], and while that didn't happen in docker/distribution, I think we want to keep the endpoint out of our distribution spec in order to avoid burdening implementors (because as Patrick pointed out [2], it's an expensive endpoint unrelated to image push/pull). [1]: opencontainers#44 (comment) [2]: distribution/distribution#653 (comment) [3]: distribution/distribution#653 (comment) [4]: distribution/distribution#653 (comment)
wking
force-pushed
the
image-repository-wording
branch
from
c2f052d to
75ede78
Compare
Contributor
|
LGTM thanks |
bsatlas
added a commit
to bsatlas/distribution-spec
that referenced
this pull request
Jan 4, 2019
This commit redefines the `_catalog` endpoint as an optional operation. Background on the issue: opencontainers#22 https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/rJ72OtZuhbc opencontainers/tob#35 opencontainers/tob#46 opencontainers/tob#50 Signed-off-by: Atlas Kerr <[email protected]>
bsatlas
added a commit
to bsatlas/distribution-spec
that referenced
this pull request
Jan 4, 2019
This commit redefines the `_catalog` endpoint as an optional operation. Background on the issue: opencontainers#22 https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/rJ72OtZuhbc opencontainers/tob#35 opencontainers/tob#46 opencontainers/tob#50 Signed-off-by: Atlas Kerr <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
@mikebrow and I have had a lengthy discussion before realizing that we were not interpreting these terms the same way. This commit replaces some explicit object-type lists with “objects defined in the image specification”, which is more concrete than using terms without local definitions. I've also added image-spec links where I do use object-type terms. And I've used the wordy but more explicit “groups of image indexes” instead of “repositories” in most cases.
I've also explicitly listed
/v2/_catalogas out of scope. It's a higher-level endpoint than the image-spec objects. As Patrick and Stephen pointed out when the endpoint landed, it's for internal administration. Matt suggested keeping it out of the user-facing API on those grounds, and while that didn't happen indocker/distribution, I think we want to keep the endpoint out of our distribution spec in order to avoid burdening implementors (because as Patrick pointed out, it's an expensive endpoint unrelated to image push/pull).