Skip to content

kube versioning document pinning edge case #75

@clux

Description

@clux

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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions