Skip to content
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

mini update 13: update definitions #177

Closed
wants to merge 24 commits into from

Conversation

pmengelbert
Copy link
Contributor

pmengelbert and others added 24 commits June 16, 2020 11:48
Signed-off-by: Peter Engelbert <[email protected]>
This is a new table of contents for the spec, designed to
add simplicity and organization.

Existing content will later be moved into one of these sections,
or removed entirely if considered superfluous.

Signed-off-by: jdolitsky <[email protected]>
Fill in the overview section, including new introduction
referring to "content" (vs. just container images).

Move historical context section underneath overview.

Signed-off-by: jdolitsky <[email protected]>
Fill in the definitions section, introducing several
terms and defintions which will serve as reference for
the rest of the document.

Also moved the "notational conventions" section into
this section, removing any language that seemed
unnecessary or related to compliance (which will be
covered in the conformance section).

Signed-off-by: jdolitsky <[email protected]>
Fill in conformance section, adding minimum requirements
stating that all compliant registries must at least support Pull.

Added a section regarding certification, linking to the
opencontainers/oci-conformance repo.

For the workflow sections, intentionally left blank, and will
be added in a follow-up PR.

Signed-off-by: jdolitsky <[email protected]>
Fill in conformance section, adding minimum requirements
stating that all compliant registries must at least support Pull.

Added a section regarding certification, linking to the
opencontainers/oci-conformance repo.

For the workflow sections, intentionally left blank, and will
be added in a follow-up PR.

Signed-off-by: jdolitsky <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
…-spec into mini-update-6

Signed-off-by: Peter Engelbert <[email protected]>
…-spec into mini-update-6

Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
Signed-off-by: Peter Engelbert <[email protected]>
@jdolitsky jdolitsky mentioned this pull request Jul 29, 2020
14 tasks
spec.md Outdated Show resolved Hide resolved

`<name>` is the namespace of the repository, and `<digest>` being the blob's digest.

A GET request to an existing blob URL MUST provide the expected blob, with a reponse code that MUST be `200 OK`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Ignorant question - is there any question of permissions here?


`<name>` refers to the namespace of the repository. `<reference>` MUST be either (a) the digest of the manifest or (b) a tag name.

The `<reference>` MUST NOT be in any other format.
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems like the two sentences referring to should be in the same paragraph?


The `<reference>` MUST NOT be in any other format.

A GET request to an existing manifest URL MUST provide the expected manifest, with a response code that MUST be `200 OK`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Again, any question of permissions or authentication here?

- **Config**: a section in the manifest (and associated blob) which contains artifact metadata
- **Artifact**: one conceptual piece of content stored as blobs with an accompanying manifest containing a config
- **Digest**: a unique identifier created from a cryptographic hash of a blob's content
- **Digest**: a unique identifier created from a cryptographic hash of a blob's content. Digests are defined under the [OCI Image Spec](https://github.com/opencontainers/image-spec/blob/b6e51fa50549ee0bd5188494912a7f4c382cb0d4/descriptor.md#digests)
Copy link
Contributor

Choose a reason for hiding this comment

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

Is that a commit id in the link? That will quickly make itself obsolete won't it?

@@ -803,7 +801,7 @@ Range: bytes=0-0
To get the status of an upload, issue a GET request to the upload URL:

```HTTP
GET /v2/<name>/blobs/uploads/<session_id>
GET /v2/<name>/globs/uploads/<session_id>
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a real thing? globs?

{
"errors": [
{
"code": "<error identifier>",
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this say "(see below)" ?

spec.md Outdated

`<name>` is the namespace of the repository, and `<tag>` is the name of the tag to be deleted. Upon success, the registry
MUST respond with a `202 Accepted` code. If tag deletion is disabled, the registry MUST respond with a `400 Bad Request`
code.
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the spec want to take a stand on auto-deletion of a manifest when the last tag to it is removed? In particular, should that be disallowed? Else clients may have to try and guess what a repo will do...

`/v2/<name>/tags/list`

`<name>` is the namespace of the repository. Assuming a repository is found, Content Discovery endpoints MUST return a
`200 OK` response code. The list of tags MAY be empty, if there are no tags on the repository. If the list is not empty,
Copy link
Contributor

Choose a reason for hiding this comment

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

nit - maybe drop the comma after 'empty'?

next), the list returned will start at the beginning of the list and include `<int>` results. As above, the tags MUST be
in lexical order.

The `last` query parameter provides further means for limiting the number of tags. It is used exclusively in combination with the
Copy link
Contributor

Choose a reason for hiding this comment

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

last seems weird. I know startafter is longer, but it's more correct, no?

@hallyn
Copy link
Contributor

hallyn commented Aug 5, 2020

(weird, gh was saying there were only 2 comments when i hit approve, so i thought maybe it was for just that commit's review. Would have marked it 'changes requested' otherwise)

@jdolitsky jdolitsky changed the title mini update 13: update definitions Distribution spec reorganization Aug 11, 2020
@jdolitsky jdolitsky changed the title Distribution spec reorganization mini update 13: update definitions Aug 11, 2020
@jdolitsky
Copy link
Member

Closing this in favor of #178

@hallyn if you could port your comments there - thank you!

@jdolitsky jdolitsky closed this Aug 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants