Add Rust implementation of CDI

[zvonkok]

Existing and upcoming projects are using Rust as the language of choice.
While the outer-runtime in Kata is written in go the inner runtime (kata-agent) is implemented in Rust.

We use CDI in the outer-runtime but the next step is to enable it in the inner-runtime as well.

Proposal to add a container-device-interface-rust repository to add a Rust implementation.

[zvonkok]

@kad @elezar @bart0sh @uniemimu WDYT?

[klueska]

also @klihub

[klihub]

If we're sure there is a need for this (and volunteers to do the Rust work) then I have no objections.

[zvonkok]

@klihub I can at least speak from the Kata Containers' perspective, and we need it and we're going to do the Rust work ( mostly me :)

[mythi]

Do we need a new repo for that or just maintain everything in this repo?

[zvonkok]

@mythi I do not have any preference, but I think it would be easier to handle Issues/PRs if they are different projects.
For things that are language-independent, we may externalize it somehow.

[zvonkok]

Any idea how to move this forward, how we should manage the added code now that we're under cncf-tags? Are we going to maintain this in this repo only?

[kad]

@zvonkok I think there are 2 possibilities to move forward quickly:

1. create rust bindings repo under Kata umbrella and later move it similarly to cncf-tags
2. other option is to request repo (similarly like it was requested for this repo in issue here: [REPO CREATION] Create container-device-interface in cncf-tags cncf/toc#1142). We as COD working group can be a sponsor for that new repo.

WDYT @elezar ?

[elezar]

Sorry for the late response I was on PTO.

@zvonkok a question to you: Would this repo only contain the rust implementation of the SPEC or all of the logic in the pkg folders?

Assuming that the injection logic is the target, I think that starting with a container-device-interface-rs repo, for example, under the kata umbrella -- or even elsewhere -- makes the most sense. We could then migrate the repo once development there has stabilised.

I'm not against sponsoring a new repo, but think that having it in place already and moving it later probably reduces the friction significantly.

Note, if it's only the spec that we're inerested in, then adding a folder:

./specs-rs`

to the existing repo may be sufficient. It may make some sense to split out the spec and the implementation at some point anyway.

[zvonkok]

Got it, doing a POC first with Kata, and when stabilized we can move over to CNCF tags!

[zvonkok]

Keeping this open for tracking, if you don't mind :)

[github-actions]

This issue is stale because it has been open 90 days with no activity. This issue will be closed in 30 days unless new comments are made or the stale label is removed.

[github-actions]

This issue was automatically closed due to inactivity.

[zvonkok]

@klihub @kad @elezar @bart0sh kata-containers/kata-containers#10059 PTAL

[elezar]

I started a discussion on the CNCF Slack: https://cloud-native.slack.com/archives/CPBE97SMU/p1722350144082649

[RobertKielty]

@elezar @zvonkok I work on the CNCF Projects / Dev Rel Team

One of the things we do on CNCF GitHub Orgs is manage access to repos.

I would suggest that you create a new repo in the cncf-tags org.

We use a tool called CLOWarden (implemented for the most part using Rust) which is a suite of components that provide us with a git-ops workflow for creating and managing access to the repos in CNCF GitHub orgs such as cncf-tags.

If you want to add a repo to cncf-tags head over to the cncf-tags/org-admin repo and follow the instructions there in the README.

[raravena80]

Can it be hosted in this repo? Or we can create a separate repo under this org. wdyt?

[RobertKielty]

Can it be hosted in this repo? Or we can create a separate repo under this org. wdyt?

Whatever makes sense for the project and the maintainers of both sets of code.

I'd offer the following points to consider in making the co-locate/new repo decision.

Contributor Colaboration
Intermingling the Rust development with Go development in the same repo will mean that the commit histories are intertwined. Is this useful for the maintainers of both codebases?

Code organization and discoverability
Given the location of both codebases in a shared org that spans multiple TAGs, how will contributors or end-users find both sets of components? What will the "sign above the door" look like in terms of knowing where the Go components reside and where the Rust compoents reside. How will end-users think of both sets of components?

Release cadence, release versioning
Should the Go and Rust components be released together in lock step so that they share the same version?

Other considerations to include would be design, testing, CI and documentation.

Whatever y'all decide we can support you either way.

[zvonkok]

I would suggest to have a separate repository we do not want to intermingle Rust/go development.
We can link from both repositories to each other saying something like if you looking for the go-bindings go here and for rust go there etc.
I do not know if we can keep up the go development since we have for now more contributors in the go version than on the rust version. I would also avoid the lockstep since the projects that are using the Rust version need different features than the go projects.