Skip to content

remove will not provide language placed on common distribution use cases #45

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

remove will not provide language placed on common distribution use cases #45

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 1 addition & 6 deletions proposals/distribution.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,7 @@ TL;DR; Move [`api.md`][api.md] to a new [distribution-spec project](https://gith
This proposal covers the distribution API spec, and while it does not cover the code for the docker-registry, that implementation is considered the reference implementation. There are other implementations of this protocol, not all are open-source though (Google gcr.io, Amazon ECR, CoreOS Quay, Gitlab registry, JFrog Artifactory registry, Huawei Dockyard, etc).

In the past when the topic of having an OCI specification around the distribution of container images was discussed, it was deferred as "let’s get the image format defined, meanwhile the industry will settle on a distribution standard". Fast forward, OCI image format is out and adopted, and the Registry v2 is the defacto standard. There is and will be use-cases for alternate methods and the future will likely hold creative ways to push, fetch and share container images, but right now this promotion serves to acknowledge by the OCI the current industry standard of distributing container images.

This proposal also provides the container ecosystem with a means to discuss and schedule extensions to the distribution specification.

There is polish that is needed e.g. broken links to storage-driver docs, as well as making sections more generic regarding the OCI descriptors and media-types, but on the whole this is a lateral move.
Expand Down Expand Up @@ -107,16 +108,10 @@ The following entries should be added to the [scope table][scope]:
Retrieving images covers the current “tag listing” (e.g. “what named manifests are in `library/busybox`?”), because tags are entries in the image format's [`manifests` array][manifests].
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.
For example, “what images are under `library/`?” is out of scope for this project.

* What: Specifying a distribution method
* In/Out/Future: In scope
* Status: In progress (see opencontainers/distribution-spec)
* Description: Define a protocol for image, manifest, config, and blob creation, retrieval, and deletion.
Listing repositories is a multi-repository action, which is out of scope for this entry.
Creating and deleting repositories are per-repository actions, which are out of scope for this entry.
Listing images within repositories is a per-repository action, which is out of scope for this entry.
Copy link
Contributor

@wking wking Mar 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather keep these limits to ensure we stay focused on push/pull for images and more granular objects. If the OCI wants to cover content-management at the repository level, that's fine with me, but I'd like it to be clearly separated from distribution so implementations could be compliant distribution engines without needing to implement repository-level operations. However, I'm happy to take that distinction up with the coming distribution maintainers if the TOB wants to punt on it by removing these lines here. More discussion in this vein in #37 and #44.

Copy link
Member Author

@mikebrow mikebrow Mar 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as enabling content-management is not the same as providing content-management, I don't think providing a list of contents to enable certain push and pull workflows is the same as "covering content-management."

Per the discussions over on 44.. If there's a phrasing you want to add to ensure the resulting spec delineates MUST items necessary to certain primary workflows and further delineates as OPTIONAL the portions of the spec not necessary for the primary workflows, that works for me.

Copy link
Contributor

@wking wking Mar 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the discussions over on #44.

I'll keep my pushback over on #44 so other folks can weigh in here with a lower comment-count ;).

* Why: This specification will provide one (of possibly many) distribution specifications.
Alternative distribution specifications may be developed for uses cases not covered by this specification, but defining them is currently out of scope for the OCI.

Expand Down