Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kubernetes version support policy #2798

Open
jaronoff97 opened this issue Mar 28, 2024 · 4 comments
Open

Kubernetes version support policy #2798

jaronoff97 opened this issue Mar 28, 2024 · 4 comments
Assignees
Labels
documentation Improvements or additions to documentation internal question Further information is requested

Comments

@jaronoff97
Copy link
Contributor

Component(s)

No response

Describe the issue you're reporting

How many versions back of Kubernetes do we support?

@jaronoff97 jaronoff97 added needs triage documentation Improvements or additions to documentation question Further information is requested internal and removed needs triage labels Mar 28, 2024
@jaronoff97
Copy link
Contributor Author

We plan to support kubernetes HEAD-6 versions, @swiatekm-sumo will bump versions once a quarter :)

This means we will support minimum inclusive of 1.24 starting in april. min 1.25 in july, min 1.26 in october and so forth.

@pavolloffay is that okay with you?

@frzifus
Copy link
Member

frzifus commented Mar 28, 2024

Should be good with openshift (https://access.redhat.com/support/policy/updates/openshift) wdyt @pavolloffay ?

@pavolloffay
Copy link
Member

@frzifus I don't think so. OCP 4.12 is based on k8s 1.25 and it will be supported until January 17, 2025 https://access.redhat.com/support/policy/updates/openshift.

Is there any technical issue that forces us to bump the minimal supported k8s version? Given that we have to support the operator on all supported OpenShift versions I would prefer to evaluate the min version update case by case.

@swiatekm
Copy link
Contributor

swiatekm commented Mar 29, 2024

@pavolloffay we'd like to have a predictable support policy, so users can anticipate when we're going to drop support. "Case by case" means we could end support for all non-EOL versions today if we wanted to, which isn't ideal.

In a practical sense, "support the same version as the most conservative distributions" sounds fine as a policy to me, but I think we'd like to link this to upstream releases, rather than force users to go check OpenShift or EKS to understand the operator's policy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation internal question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants