[
https://issues.apache.org/jira/browse/SPARK-26973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16775435#comment-16775435
]
Erik Erlandson commented on SPARK-26973:
----------------------------------------
A couple other points:
* Currently, k8s is evolving in a manner where breakage of existing
functionality is low probability, and so testing against the earliest version
we wish to support is probably optimal in a scenario where we are choosing one
version to test against. (This heuristic might change in the future, for
example if k8s goes to a 2.x series where backward compatibility may be broken)
* The integration testing was designed to support running against external
clusters (GCP, etc) - this might provide an approach to supporting testing
against multiple k8s versions. However, it would come with additional op-ex
costs and decreased control over the environment. I mention it mostly because
it's a plausible path to outsourcing some of the combinatorics that
[~shaneknapp] discussed above
> Kubernetes version support strategy on test nodes / backend
> -----------------------------------------------------------
>
> Key: SPARK-26973
> URL: https://issues.apache.org/jira/browse/SPARK-26973
> Project: Spark
> Issue Type: Test
> Components: Kubernetes
> Affects Versions: 3.0.0
> Reporter: Stavros Kontopoulos
> Priority: Major
>
> Kubernetes has a policy for supporting three minor releases and the current
> ones are defined here:
> [https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md.|https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md]
> Moving from release 1.x to 1.(x+1) happens roughly every 100
> days:[https://gravitational.com/blog/kubernetes-release-cycle.]
> This has an effect on dependencies upgrade at the Spark on K8s backend and
> the version of Minikube required to be supported for testing. One other issue
> is what the users actually want at the given time of a release. Some popular
> vendors like EKS([https://aws.amazon.com/eks/faqs/]) have their own roadmap
> for releases and may not catch up fast (what is our view on this).
> Follow the comments for a recent discussion on the topic:
> [https://github.com/apache/spark/pull/23814.]
> Clearly we need a strategy for this.
> A couple of options for the current state of things:
> a) Support only the last two versions, but that leaves out a version that
> still receives patches.
> b) Support only the latest, which makes testing easier, but leaves out other
> currently maintained version.
> A good strategy will optimize at least the following:
> 1) percentage of users satisfied at release time.
> 2) how long it takes to support the latest K8s version
> 3) testing requirements eg. minikube versions used
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
