-
Notifications
You must be signed in to change notification settings - Fork 205
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
Conversation
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]>
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]>
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]>
…-spec into mini-update-6 Signed-off-by: jdolitsky <[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]>
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]>
|
||
`<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`. |
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.
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. |
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.
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`. |
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.
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) |
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.
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> |
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.
Is this a real thing? globs?
{ | ||
"errors": [ | ||
{ | ||
"code": "<error identifier>", |
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.
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. |
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.
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, |
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 - 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 |
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.
last seems weird. I know startafter is longer, but it's more correct, no?
(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) |
This PR is based on #175 .
See the relevant diff below:
https://github.com/bloodorangeio/distribution-spec/compare/mini-update-12...bloodorangeio:mini-update-13?expand=1