Drive CDI specification to v1.0.0

[elezar]

This issue serves as a top-level tracker for achieving a v1.0.0 CDI specification.

See the discussions here:

• May 16 2023
• April 16 2024

• Move version APIs to the specs-go package #214
• Document fields in spec to indicate when these were added. #215
• Document the version match process when loading specs. #231
  • Currently we fail on unknown fields and then we check whether the version field in the spec file is supported by the consumer. We also use golang null default values for all new fields so that these remain valid when loading older spec versions.
• Split API into two sections: Producer vs Consumer #230
  • producer: Minimum spec version: https://github.com/NVIDIA/nvidia-container-toolkit/blob/f794d09df19b628232d872470772b50f34b45ae8/pkg/nvcdi/spec/set-minimum-version.go#L28
• Remove deprecated APIs
  • Remove deprecated oci and qualified-device APIs #218
  • Remove deprecated registry API #219
• Remove dependency on runtime-spec from spec-go for producer API
  • Remove the ToOCI functions from the specs-go package #208
• Code cleanup
  • golangci-lint reports errors #222
  • Code cleanup #223
  • Inconsistent naming of the specs-go module #227
• Ensure that YAML marshalling maintains field ordering #235
• [nice-to-have] Automated checks for parity between Go and Rust implementations
• [nice-to-have] Add reference implementation for hooks
  • Add description of standard hooks #225

[bart0sh]

@elezar @klihub should we also remove all deprecated APIs in v1.0.0 ?

[elezar]

@elezar @klihub should we also remove all deprecated APIs in v1.0.0 ?

Yes, that sounds reasonable.

[klihub]

@elezar @klihub should we also remove all deprecated APIs in v1.0.0 ?

Yes, that sounds reasonable.

Yup, we can do that, too.

[bart0sh]

@elezar @klihub Considering quite substantial amount of changes in #233, I started to worry about API stability. The change is too big to guarantee that CDI 1.0 is still stable from my point of view. Should we postpone it or do only small amount of changes, e.g. introduce a producer package and simple spec writing function(s)?

[elezar]

@bart0sh I think we should differentiate between specification stability and API stability. Note that although #233 adds a number of files, there are no changes to the spec and the changes to existing functionality is limited to the parts of the cache that are concerned with writing specs and validation. I don't think #233 should block a spec v1.0.0 release though. Do you have insights as to whether a v1.0.0 spec is considered a requirement for DRA going beta in the v1.32 k8s release (which was the original driver for this issue).

[pohly]

v1.0.0 is not a blocker for beta. It probably is for GA.