Regression test approach in rke2 for CRI compatibility #3818
Replies: 2 comments 1 reply
-
We don't validate use with anything other than the packaged containerd version. While the option currently exists and should be usable, I don't believe it currently falls within our support boundary. We build Kubernetes directly from the upstream source, and RKE2 should support any container runtime with CRI support, but if you run into issues using a different runtime we may ask you to confirm that you don't experience the same issue using the containerd binary that ships with RKE2. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick response! As a follow-up, is your validation approach a kind of automated test that we could re-use to put a different container runtime through for validation? I think that we'd be able to rationalize the use and support of something other than containerd if the vetting/validation verification process imposed a reasonably small burden. |
Beta Was this translation helpful? Give feedback.
-
Hello all,
I've followed issue 3219 (#3219) to its successful conclusion - we are interested in this kind of compatibility for other container runtime engine support in rke2 - but it did leave me wondering what kinds of tests are contained in the release work-flow of rke2 to explicitly validate CRI compatibility.
I'm interested because, if we have to choose CRI-O, for example, for specific feature support, there seems to always be the possibility that, like issue 3219 exemplifies, an innocuous change in the baseline for an update could break support for engines other than containerd.
Is there an explicit battery of tests for CRI, or is it more left to the outside users to find and submit issues in compatibility?
Not trying to be critical; just looking for information on process and support. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions