-
Notifications
You must be signed in to change notification settings - Fork 25
Open
Description
https://kube.rs/kubernetes-version/#version-skew does not account for need to "not accidentally take a dependency on a new kubernetes version" by means of utilising new optional fields in stable apis.
briefly discussed in a public discord thread. important excerpt:
16:18]natkr: I think the biggest reason is the opposite, avoiding accidentally taking a dependency on a newer version
[16:19]natkr: though the API level method is.. kind of a large sledgehammer for that
[16:19]natkr: and there's also a lot of variance in needs between.. "I want to deploy to my corporate cluster that I already test against" and "we're an ISV that needs to deploy to customers' ancient OpenShift clusters"
[16:20]natkr: and everything in between
[16:21]clux: hm, is kubernetes not forwards compatible towards new optional fields?
[16:21]natkr: I mean
[16:22]natkr: IIRC it will ignore unknown fields unless you opt into strict validation
[16:22]natkr: but that won't help you if your app depends on the behaviour of those new fields
[16:22]natkr: (or, alternatively, needs to read them for whatever reason)
[16:29]clux: sounds sensible though. i might need to add more to the above versioning doc then.
[16:30]natkr: that said, we specifically do tend to track the latestish api levels
[16:30]natkr: It's Complicated™️ :/
[16:30]natkr: it's definitely not a perfect solution
[16:30]natkr: and I don't know if there is one
Metadata
Metadata
Assignees
Labels
No labels