kuberay
kuberay copied to clipboard
ray-project
[Feature] Publicize the stability timeline
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
Description
We must let users know when Kuberay will be in Beta and Kuberay will be in GA (which Ray release).
Use case
This is very simple and will help users deploying Ray communicate it to their organization.
Related issues
No response
Are you willing to submit a PR?
- [ ] Yes I am willing to submit a PR!
cc @Jeffwan to help us understand the context of KubeRay stability and user-readiness
I'd be willing to pick this up (RE: creating and maintaining a public-facing roadmap on GitHub, as a project board).
Very relevant here is the Ray 2.0.0 roadmap https://github.com/ray-project/ray/issues/22833
As we mention there, we aim to reach GA for KubeRay for at the Ray 2.0.0 release in August.
Some notes on what's meant by GA --
I think KubeRay and the KubeRay controller in particular are already quite stable -- this is thanks to the work of @akanso @Jeffwan and others who have built and maintained this project.
By "GA", we mean GA from the perspective of the Ray maintainers. The definition is approximately this: All core Ray functionality and integrations (included Autoscaling) work well with KubeRay, are well-tested, and are well-documented in the Ray docs (with links to the KubeRay docs where appropriate).
The goal is for KubeRay to be the preferred mechanism for deployments of Ray on Kubernetes.
We can break down into phases. Before GA, do we want to move to Beta first? What's the Beta definition in Ray community? I am also considering the scope, operator is the most important and critical components. Beside that, we have other components being developed like backend service, workspace (coming soon). Do we want to promote other components to GA at the same time or have separate schedule for them? (from Ray core perspective, seem we only care about operator?)
Before GA, do we want to move to Beta first?
Yes, for sure -- there's currently some internal discussion among the Ray maintainers whether this should be achieved by shooting for Beta in Ray 2.0.0 and GA in Ray 2.1.0 OR Beta in a Ray 2.0.0rc0 release and GA in Ray 2.0.0.
scope
This is a good point and it indeed might make sense to have separate timelines for these components. From the Ray core perspective, the goal is to have a clear path to using all of Ray's functionality on K8s, using the KubeRay operator as the engine for infrastructure.
Closing for the sake of cleanup. 0.5.0 release planning is discussed here: https://github.com/ray-project/kuberay/issues/853