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.

[bart0sh]

@elezar @klihub There are already quite a bit of changes between main branch and the latest release:

$ git diff v0.8.0  | wc -l
3466

Pending PRs will probably double this count if we merge them. Which is fine, unless we really want to make a 1.0 a stable release. Do we?

If we do, in my opinion, we should consider carefully picking up only fixes and documentation improvements and making 1.0 out of them. We can then gradually add more changes in dot releases.

Opinions?

[bart0sh]

The title of this issue suggests that the scope of it is just the CDI Spec, not the API. Is it still the case?

[klihub]

The title of this issue suggests that the scope of it is just the CDI Spec, not the API. Is it still the case?

Then again, some of the TODO items, like 'Split API into two sections: Producer vs Consumer' or 'Automated checks for parity between go and Rust implementations' suggest that this is about both the CDI Specification and the implementation/API.

[bart0sh]

So, we need to either update the issue title or the TODO list. I'd say it's probably safer to update the TODO list as it will reduce amount of changes we want to make to resolve this issue.