Proposal I - compatibilities extension in image index platform and image manifest config by ChaoyiHuang · Pull Request #19 · opencontainers/wg-image-compatibility

ChaoyiHuang · 2024-06-11T08:32:01Z

This proposal is born from proposal A to H.

The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI.

This proposal is born from proposal A to H. The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI. Signed-off-by: joehuang <joehuang.sweden@gmail.com>

mfranczy · 2024-06-11T10:53:15Z

@@ -0,0 +1,235 @@
+# Proposal I - compatibilities extention in platform object


s/extention/extension/g

OK, update in next commit

mfranczy · 2024-06-11T11:06:23Z

Definetely the idea of adding a new compatibilities field in the index that is a descriptor is interesting.
As mentioned in the comment, if we go that way we should create a new media type application/vnd.oci.image.compatibility.v1+json and provide its own properties (probably the one we wanted for artifact).

I also like the idea because compatibility would be under the image spec. If container runtimes want to support it they would not have a lot of additional API calls.

vsoch · 2024-06-11T13:27:08Z

+
+This proposal is born from proposal A to H.
+
+The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI.


Suggested change

The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI.

The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining a standalone artifact in OCI.

ok, will update in next commit

vsoch · 2024-06-11T13:27:19Z

+
+The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI.
+
+## image spec platform object extention


Suggested change

## image spec platform object extention

## image spec platform object extension

yeah, spelling issue. will fix

vsoch · 2024-06-11T13:29:49Z

+
+### add platform.compatibilities descriptor
+
+Add a new descriptor in platform object in [image index](https://github.com/opencontainers/image-spec/blob/main/image-index.md#image-index-property-descriptions).


Doesn't this still imply another artifact, it's just linked to differently, directly from a manifest list?

The idea here is to address our concerns in current OCI specifications, avoid introduing a new standalone spec ( maintainers worried about new standard to maintain). so just add new descriptor in manifest entry's platform objector in image index, the descriptor will point to a manifest, in which the compatibilities could reside in config(the current commit), or in a new mediatype layer(another option).

it can be handled quite similar to artifact, but no need to use referrers api anymore.

the compatibilities now can be decoupled from container lifecycle，and optional for runtime engine, runtime engine can be configured to use the compatibilities or not, in sync or async order, it's easy for runtime engine to evolve.

vsoch · 2024-06-11T13:30:34Z

+
+    - **`features`** _array of strings_
+
+    - **`compatibilities`** _[descriptor](https://github.com/opencontainers/image-spec/blob/main/descriptor.md)_


This is confusing because now I'm thinking the field "compatibilities" is part of a descriptor.

maybe another term would be better. your suggestion?

vsoch · 2024-06-11T13:32:05Z

+
+## Compatibilities Manifest
+
+The compatibilities manifest is a special image manifest, contains only config and no blob layer.


So this is another link / redirection to get to the compatibilities? If I understand:

image manifest list -> descriptor -> image manifest -> config (which has them)?

So this is another link / redirection to get to the compatibilities? If I understand:

image manifest list -> descriptor -> image manifest -> config (which has them)?

yes, this is the path to get the compatibilities content.

will submit another proposal to short the path by adding a new mediatype, as commented by Marcin

vsoch · 2024-06-11T13:32:50Z

+
+### Config Extention
+
+The config object will be extened with compatibilities field.


Does this mean we need to do diffs and similar if you are combining layers from multiple images / multiple configs?

no need. in this config, only compatibilities is valid content.

vsoch · 2024-06-11T13:34:17Z

+#### Example - image is compatible with different hardware combinations
+
+```json
+{


This looks like just slightly changing the format / structure to look like a config over an artifact. There are still many jumps to get here - I'm not sure why this approach is better? It has more down sides, like requiring the person own the image / registry URI to be able to update or define the compatibilities. And then the issue of changing digests.

for jump, it's similar as artifact.

It has more down sides, like requiring the person own the image / registry URI to be able to update or define the compatibilities. And then the issue of changing digests.

it's quite easy to update compatibilites, just replace the descriptor in the image index manifest entry. and the image manifest and blob layes itself doesn't need to update (no rebuild and redistribution), the image manifest digest didnot change. it's very flexible while keep current flow unchanged.

…config This proposal is born from proposal A to H. Based on the maintainers feedback, The purpose of the proposal, is to address the concern maintaining standalone artifact in OCI. Spec update is done on image index platform and image manifest config. Signed-off-by: joehuang <joehuang.sweden@gmail.com>

sudo-bmitch

Putting this on hold until we can discuss the risk of unexpected data loss.

sudo-bmitch · 2024-06-14T19:49:47Z

+
+### add platform.compatibilities descriptor
+
+Add a new descriptor in platform object in [image index](https://github.com/opencontainers/image-spec/blob/main/image-index.md#image-index-property-descriptions).


Same issue that I raised on J: I have concerns that this descriptor would not be known to existing registries and client tooling. As a result, registries would accept an incomplete manifest, or silently delete the compatibility blob in a later GC cycle. And client tooling to copy images would fail to include the compatibility blobs.

@sudo-bmitch is right, so far I confirmed that with regclient and zot registry.
For this proposal we would have to add a descriptor support to regclient and zot.
Didn't test other registries and tools yet.

ChaoyiHuang requested review from cyphar, mfranczy, neersighted, sudo-bmitch and vsoch as code owners June 11, 2024 08:32

ChaoyiHuang force-pushed the proposal-i branch 2 times, most recently from 64ae3a0 to 4eb6b43 Compare June 11, 2024 08:42

Proposal I - - compatibilities extention in platform object

746c9d3

This proposal is born from proposal A to H. The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI. Signed-off-by: joehuang <joehuang.sweden@gmail.com>

ChaoyiHuang force-pushed the proposal-i branch from 4eb6b43 to 746c9d3 Compare June 11, 2024 08:50

mfranczy reviewed Jun 11, 2024

View reviewed changes

Comment thread docs/proposals/PROPOSAL_I.md Outdated

vsoch reviewed Jun 11, 2024

View reviewed changes

ChaoyiHuang force-pushed the proposal-i branch from b08fcce to 22ebd82 Compare June 12, 2024 02:46

ChaoyiHuang changed the title ~~Proposal I - - compatibilities extention in platform object~~ Proposal I - compatibilities extension in image index platform and image manifest config Jun 12, 2024

ChaoyiHuang force-pushed the proposal-i branch from 22ebd82 to abc374c Compare June 12, 2024 09:28

sudo-bmitch requested changes Jun 14, 2024

View reviewed changes

		@@ -0,0 +1,235 @@
		# Proposal I - compatibilities extention in platform object


		The purpose of the proposal, based on the maintainers feedback, is to address the concern maintaining standalone artifact in OCI.

		## image spec platform object extention

	## image spec platform object extention
	## image spec platform object extension


		### add platform.compatibilities descriptor

		Add a new descriptor in platform object in [image index](https://github.com/opencontainers/image-spec/blob/main/image-index.md#image-index-property-descriptions).


		- `features` _array of strings_

		- `compatibilities` _[descriptor](https://github.com/opencontainers/image-spec/blob/main/descriptor.md)_


		## Compatibilities Manifest

		The compatibilities manifest is a special image manifest, contains only config and no blob layer.


		### Config Extention

		The config object will be extened with compatibilities field.

Conversation

ChaoyiHuang commented Jun 11, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mfranczy commented Jun 11, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChaoyiHuang Jun 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChaoyiHuang Jun 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sudo-bmitch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ChaoyiHuang Jun 12, 2024 •

edited

Loading

ChaoyiHuang Jun 12, 2024 •

edited

Loading