Comments (7)
@sudo-bmitch Looking at containers/image, I think the changes are very useful and I have no concerns with the spec.
It will take some time for the “MUST” compatibility mechanisms on manifest upload / deletion to be implemented, though — both to just implement them (they don’t exist right now in c/image), for the implementations to propagate to supported products, and ultimately for users to upgrade their stable systems which can already upload OCI manifests. So I’m not sure that the “MUST” requirements, in practice, provide a guarantee any other part of the ecosystem can rely on, outside of repos with strictly controlled writers (which don’t really EDIT need this world-wide spec guarantee to impose that strict control).
from image.
#2062 fixes the low-hanging fruit.
More is tracked by RH as https://issues.redhat.com/browse/RUN-1880 .
from image.
@sudo-bmitch Looking at the distribution spec so far, I have filed opencontainers/distribution-spec#454 . I don’t think that’s blocking the spec release at all.
Note to self - distribution spec changes:
- A new possibility to mount a blob without specifying the source repo. “MAY” be supported; failure still initiates an upload. Probably not worthwhile right now, worth at least a comment in code. Possibly relevant for #1645 .
- New referrers list endpoint: https://github.com/opencontainers/distribution-spec/blob/6bc87156eacf3b73362db343eb6b63d7abeedf7e/spec.md#listing-referrers (writes are implied by manifest uploads). Allows filtering by a single MIME type (at least distribution/distribution#3834 suggests only one MIME type).
- Compatibility: emulating
subject
support via a tag convention.- Required (MUST) to emulate when uploading a manifest
- Required (MUST) to emulate when querying for referrers
- Recommended (SHOULD) to emulate support when deleting a manifest
- “If a client receives
Warning
response headers, it SHOULD report the warnings to the user in an unobtrusive way.
Clients SHOULD deduplicate warnings from multiple associated responses.”
Other spec points of note:
- (Recorded elsewhere) Deleting a tag, not a manifest by digest, is possible
- “A 4XX response code from the registry MAY return a body in any format” (contra the traditional docker/distribution implementation), but if it is JSON, there is a mandatory format.
from image.
Note to self — image spec changes:
- New
os.*
andvariant
,ArgsEscaped
fields in image config — probably mostly irrelevant, but see e.g.checkImageDestinationForCurrentRuntime
. OTOH Podman might need to update how it creates runtime-spec data, per https://github.com/opencontainers/image-spec/blob/main/conversion.md : containers/podman#19459 . -
data
property in descriptors — probably consume it, and possibly produce it (with what heuristics?) -
artifactType
property in descriptors — seems irrelevant right now -
subject
field on both manifests and image indices. -
artifactType
in manifests; “ theconfig.mediaType
is set to the empty value, theartifactType
MUST be defined.” - “Any extra fields in the Image JSON struct are considered implementation specific and MUST NOT generate an error by any implementations which are unable to interpret them.” - probably worth adding a test. (OTOH they are also ignored on format conversions)
- “Implementations processing content SHOULD NOT generate an error if they encounter an unknown property in a known media type.” [Sure, but to be explicit that data is just lost on edits.] Probably worth adding tests, both for parsing in general, and possibly that no-edit copies don’t lose that data.
- (Entries in index’
manifests
:) “An encounteredmediaType
that is unknown to the implementation MUST NOT generate an error.” - (Manifest itself:) “An encountered
mediaType
that is unknown MUST NOT generate an error.” - “Implementations storing or copying image manifests MUST NOT error on encountering a [config MIME type] value that is unknown to the implementation.”, and “MUST NOT attempt to parse the referenced content if this media type is unknown”
- Manifests’
layers
“SHOULD have at least one entry”, i.e. we should not break on 0 (but there MUST be a layer on on a non-artifact) - Manifests’
layers
“Implementations storing or copying image manifests MUST NOT error on encountering amediaType
that is unknown to the implementation.” -
application/vnd.oci.empty.v1+json
for “unused descriptors” — we probably don’t need to treat that specially.
Other spec points of note:
- “JSON content SHOULD be serialized as canonical JSON”
-
specs-go/v1/Image{LayoutFile,LayoutVersion,IndexFile,BlobsDir
should be used in theoci*
transports.
from image.
I think the idea is it's basically "MUST" if one claims/advertises 1.1 support/compliance.
from image.
I think the idea is it's basically "MUST" if one claims/advertises 1.1 support/compliance.
That's exactly it. The "MUST" sections turn into a conformance test for registries to advertise support for 1.1 conformance. For clients, it's good to ensure you have support for older and non-conformant registries.
from image.
distribution/distribution
is waiting for the release to be cut before implementing the changes (see distribution/distribution#3834 (comment)).
from image.
Related Issues (20)
- Support for structured logging (using `log/slog`) HOT 5
- proposal: Support append images into docker archive HOT 1
- Make a new release HOT 2
- Docker client code can no longer talk to the latest verson of the docker daemon 25.0.0 HOT 5
- Allow empty OCI configs for artifacts HOT 9
- policy.json overwrite not honouring $XDG_CONFIG_HOME HOT 3
- Podman cannot pull image from local registry HOT 4
- copy.Options.EnsureCompressionVariantsExist doesn’t detect existing variants with zstd:chunked
- support multiple sigstore keys HOT 6
- How can I copy from a tar file stream HOT 7
- "slices" module only in go 1.21 HOT 1
- platform.WantedPlatforms is noisy on macOS HOT 7
- Cannot pull sigstore signed image with podman HOT 4
- Error inspecting local manifest-lists HOT 6
- Incorrect syntax highlighting in containers-transports.5
- Why do we get the whole image when inspect with docker daemon? HOT 2
- Support sigstore BYO PKI verification HOT 1
- Support more arbitrary credential helper executable names? HOT 4
- OCI image index loose the artifactType property on copy HOT 4
- zstd:chunked and layer encryption don’t make sense together
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from image.