Clarification around os.features

[kzys]

We are planning to support os.features in containerd's platforms package. However the spec is unclear about the allowed characters regarding each feature.

containerd/platforms#16

Should we consider "/" or "+" as supported parts of OS features here? Right now the spec does not specify but we can define our own limitations. We could support it either by updating the parser (less backwards compatible) or URL encoding (ugly, but could be an edge case so who cares).

I'd like to have rough consensus (even without formalization) before having that in containerd side. Can we just limit that to, let's say [A-Za-z0-9]+?

[tianon]

Is there something in particular you're hoping to use os.features for? It's not super well defined right now, and the only actually specified value (and the only one I've really seen in the wild) isn't really all that meaningful/useful:

• os.features array of strings

  This OPTIONAL property specifies an array of strings, each specifying a mandatory OS feature.
  When os is windows, image indexes SHOULD use, and implementations SHOULD understand the following values:

  • win32k: image requires win32k.sys on the host (Note: win32k.sys is missing on Nano Server)

  When os is not windows, values are implementation-defined and SHOULD be submitted to this specification for standardization.

https://github.com/opencontainers/image-spec/blob/v1.1.0/image-index.md#:~:text=on%20windows.-,os.features,-array%20of%20strings

[sudo-bmitch]

There have been discussions on whether to use the platform.features for fine grain image compatibility happening in the working group. However that effort is not finished, so I don't think OCI has any recommendations yet. Feedback from the implementations leveraging fine grain image selection would be good to hear.

For the Windows usage, my impression from #1147 is that os.features is no longer needed, and is being kept around pending the working group result.

[kzys]

I don't think we (containerd) have specific use cases to be honest. The PR is more about making our Platform compatible with the spec's Platform.

cc @dmcgowan - Please correct me if I'm wrong.