Proposal I - compatibilities extension in image index platform and image manifest config #19

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 <[email protected]>

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

docs/proposals/PROPOSAL_I.md

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


s/extention/extension/g

OK, update in next commit

docs/proposals/PROPOSAL_I.md

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

docs/proposals/PROPOSAL_I.md

+
+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

docs/proposals/PROPOSAL_I.md

+
+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

docs/proposals/PROPOSAL_I.md

+
+### 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

docs/proposals/PROPOSAL_I.md

+
+    - **`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

docs/proposals/PROPOSAL_I.md

+
+## 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

docs/proposals/PROPOSAL_I.md

+
+### 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

docs/proposals/PROPOSAL_I.md

+#### 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 <[email protected]>

sudo-bmitch

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

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

docs/proposals/PROPOSAL_I.md

+
+### 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 mfranczy, vsoch, sudo-bmitch, cyphar and neersighted 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 <[email protected]>

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

docs/proposals/PROPOSAL_I.md Outdated Show resolved Hide resolved

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal I - compatibilities extension in image index platform and image manifest config #19

Proposal I - compatibilities extension in image index platform and image manifest config #19

ChaoyiHuang commented Jun 11, 2024

mfranczy Jun 11, 2024

ChaoyiHuang Jun 12, 2024

mfranczy commented Jun 11, 2024

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024 •

edited

Loading

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024

vsoch Jun 11, 2024

ChaoyiHuang Jun 12, 2024 •

edited

Loading

sudo-bmitch left a comment

sudo-bmitch Jun 14, 2024

mfranczy Jun 17, 2024

		@@ -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.

Proposal I - compatibilities extension in image index platform and image manifest config #19

Are you sure you want to change the base?

Proposal I - compatibilities extension in image index platform and image manifest config #19

Conversation

ChaoyiHuang commented Jun 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfranczy commented Jun 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChaoyiHuang Jun 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChaoyiHuang Jun 12, 2024 • edited Loading

Choose a reason for hiding this comment

sudo-bmitch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChaoyiHuang Jun 12, 2024 •

edited

Loading

ChaoyiHuang Jun 12, 2024 •

edited

Loading