-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
distribution: Reword scope table to avoid repository/image distinction #46
distribution: Reword scope table to avoid repository/image distinction #46
Conversation
bb4908e
to
8dd6a19
Compare
d00d12a
to
c2f052d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ping @caniszczyk, now that @mikebrow and I are on the same page ;). |
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]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: s/registery/registry/ here and below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: "Grouping image indexes ... is out of scope..."
or even:
"...is considered part of distribution policy or content management, which are out of scope..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
c2f052d
to
75ede78
Compare
LGTM thanks |
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 <atlaskerr@gmail.com>
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 <atlaskerr@gmail.com>
@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/_catalog
as 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).