Match and Compare platforms with OSFeatures

[dmcgowan]

Add-on to #16

This allows using the OSFeatures field for matching and comparing. To match, the checked platform's features must be a subset of the matcher's platforms. The matcher platform represents the supported features by the host and the checked platforms the platform needed for each image in an index or used to match a plugin instance.

This provides a way to add feature variation in a backwards compatible wherever platform matching is involved.

[dmcgowan]

I proposed this as a cleaner solution to containerd/containerd#12784. Using the feature in the platform, the manifest selection logic can prefer an erofs manifest based on the availability of the snapshotter.

[hsiangkao]

I proposed this as a cleaner solution to containerd/containerd#12784. Using the feature in the platform, the manifest selection logic can prefer an erofs manifest based on the availability of the snapshotter.

@dmcgowan I hope we could move forward for v2.3, but anything somewhat relating to OCI just s*cks..

[fuweid]

2 years? :)

[tonistiigi]

iiuc this is backwards. normalized is the manifest platform, but manifest platforms should be subset of daemon/matcher platform, not the other way around.

[hsiangkao]

Anyway, what I can think out is that I think we could differentiate which kinds of os.features we need to Match (For example, I can think out adding some prefix or a single-char annotation for example); Other os.features (including win32k or random previous garbage os.features generated by vendors) will not be considered as a part of Match.

But all os.features will be participate in sorting and formating.

[hsiangkao]

Otherwise, if no Match functionality for some erofs os.features for example, it will make such os.features just another random flag, and almost useless except another kind of a comment for human beings somewhere.