-
Notifications
You must be signed in to change notification settings - Fork 0
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 manifest #1
base: universal
Are you sure you want to change the base?
Distribution manifest #1
Conversation
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
@@ -77,89 +80,156 @@ The `objects` each correspond to items that the client may wish to process, and | |||
|
|||
Standard OCI annotations as per existing standards, this is metadata that may have common fields across different objects. Arguably this should be a map of string to string array so that annotation keys can be repeated, so they map better to other structures (such as http headers) that allow repetition. | |||
|
|||
- **any other data** *unspecified* | |||
- **`ext_`*** *unspecified* |
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.
I'm still a bit nervous about this one as it's ripe for namespace conflicts for groups that wish to use similarly named properties.
I'm thinking about namespaces scoped sections. Does anyone know of any good examples to use?
|
||
- **any other data** *unspecified* | ||
- **`ext_`*** *unspecified* |
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.
same concern as above
"mediaType": "application/vnd.oci.layer.encrypted", | ||
"version": "2", | ||
"descriptor": { | ||
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip+encrypted", |
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 +encrypted going to get bikesheded as an example? Should we use a different example of different layers?
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
distribution-manifest.md
Outdated
|
||
### OCI Image with Alternate Persistence | ||
|
||
To support multiple versions of an artifact, the collection of components can be expanded. In the below case, the `"compType": "application/vnd.oci.layer"` is used for standard oci images. With an additional collection of layers persisted as `"compType": "application/vnd.oci.layer.encrypted"`. A client that is unable to parse the encrypted content would pull blobs with: `"compType": "application/vnd.oci.layer"`. While clients capable of pulling encrypted layers pull the encrypted components. |
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.
This doesn't work, you have to use filters for this. This is the current issue, a client that understands both types would have to know out of band that it should only use layers of the "encrypted" type, so it has to know some sort of out of band priority and rules. The format should make it clear that these are strictly alternative, not just a list of items.
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.
Two thoughts:
- Is this a good example of something we can do in phase 2, and we should split the PR into what we'll implement for this summer, vs. later
- Since there are different
compTypes
ormediaTypes
in the lastest PR, shouldn't a client know how to process what it knows and ignore the things it doesn't? And, newer versions can choose? I thought the filters were just for architecture, and not for versioning. Or, if a client couldn't know how to process filters, wouldn't they know how to process thecomponent.mediaTypes
? Or, is there a more generic thing you'd like to accomplish, and we can create a better example?
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
Edits to include examples and some name change suggestions.
type
=artifactType
rType
=object.type
cType
=mediaType
other
=ext_*
- although I'm concerned around namespace collision