Automate guarantee that mk8sv is satisified

[aviramha]

Followup from:

I think this breaks the Kubernetes version guarantee - requires openapi to upgraded to
1.31 to compile kube-rs as a dependency. @clux

Originally posted by @aviramha in #1605 (comment)

An innocent change broke that guarantee and could've slipped to a release.
Opening this issue to discuss how we can guarantee that this doesn't happen in the future.
My suggestion is to change the dev dependency of openapi to use mk8sv (perhaps run tests both on latest and mk8sv?)

Happy to hear other suggestions

[clux]

It's funny because we do run the tests on both versions, but there's clearly a gap here since this got through.

Thanks for raising.

[aviramha]

Yeah it's runtime vs compilation - the new version will run on older clusters, just won't compile with "old" openapi

[clux]

Yeah. Tbh, this is a reason why parts of me wants to drop k8s-openapi's version choice and turn it into fixed latest because the runtime is way more important than the schemas. If we pin latest we can:

• drop all the feature madness, e2e tests actualling un-defaulting the feature, and adding in earliest*
• re-export k8s-openapi exports under a namespace (as in here)
• avoid people having to update k8s-openapi and kube together (we pin, you get updates)

It's also the versioning strategy most other kubernetes tools on the go side uses (update client-go? cool, dont' stray too far, here's a compatibility matrix, but you get updated structs anyway).

The alternative here is doing more like what we do in the e2e style tests (which do actually run both feature versions).

[aviramha]

Okay, sounds like a good plan to me. It's less backward compatible but good trade offs in terms of usability/maintenance and if it's the standard then no reason to stray from that.