Staging Repositories for CRI Streaming

[Davanum Srinivas]

Folks,

One of the topics we had in the recent Annual containerd maintainers meeting was around the existing tech debt of sync-ing / copy-ing files manually every time we make a change in kubernetes for cri streaming into containerd. CRI-O also imports what we provide, but does not have exactly the same problems as containerd.

Some notes from the discussion:

• Mike: containerd imports k8s streaming code, which transitively depends on a lot of apimachinery code, which forces us to sync with k8s repos when we want to bump the CRI version
• Dims: There’s still an issue with importing CRI streaming code which will require the min golang bump
• Can we also have a CRI streaming repository that is also staged, minimal dependencies, so we don’t have to maintain a fork in containerd
• Tim: +1 to Dims, CRI streaming changes are minimal and are independent of any interface changes, makes sense to split this out into a staging repo
• Dims: CRI streaming repo needs to rely on min golang features, we need to revisit the things the streaming library needs and ensure they’re all on lower go versions, maybe need automation to catch these cases
• Tim: I don’t think the CRI streaming repo needs to be a staging repo, it could be separate from the staging setup
• Dims: It likely does need to be staging (or at least start there), testing wise it depends on a lot of additional k8s stuff

So here's my attempt at the first step. breaking stuff logically to make it really easy for consumers to pick up just the code they need and DOES NOT drag all the huge dependencies that they currently end up dragging into consuming repos.

https://github.com/kubernetes/kubernetes/pull/137298 

Please take a look. We are looking at 2 new staging repos. 

• staging/src/k8s.io/streaming/
• staging/src/k8s.io/cri-streaming/

(The split is to ensure OTHER staging repos don't get polluted with things that are only needed by cri-streaming).

Happy to debate on the PR or on this thread.

Thanks,
Dims

--

Davanum Srinivas :: https://twitter.com/dims

[Davanum Srinivas]

FYI there's some traffic on slack thread:
https://kubernetes.slack.com/archives/C0BP8PW9G/p1772499743362719

Created a k/org request for the sig node chairs/leads to approve:

https://github.com/kubernetes/org/issues/6189

[Benjamin Elder]

+1, I'm also looking into making relaxing the min go version for individual staging modules safer:

https://github.com/kubernetes/kubernetes/pull/137465

--
You received this message because you are subscribed to the Google Groups "sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-architectu...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CANw6fcHCzAxcgoC0rsMmKvBDpA%3DvHNSHgyN-J7i-NxD-PJpipQ%40mail.gmail.com.

[John Belamaric]

+1 here from sig-arch, also added to the issue

--
You received this message because you are subscribed to the Google Groups "sig-node" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-node+u...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-node/CANw6fcHCzAxcgoC0rsMmKvBDpA%3DvHNSHgyN-J7i-NxD-PJpipQ%40mail.gmail.com.