kuberay
kuberay copied to clipboard
ray-project
[Feature][RFC] RayCluster CRD: interface cleanup
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
Description
Minimal configuration for RayCluster CRs should be as simple as possible. Some suggestions:
- Make rayStartParams optional. If specifying
{}is valid, not specifying the field at all should also be valid.- Most users shouldn't have to specify any rayStartParams at all.
- Consider always adding
--block. The current default behavior of adding a "sleep infinity" after ray start is unintuitive and probably incorrect.
- Make serviceType optional. Default to ClusterIP -- this is K8s's default and what most users would expect.
Use case
Make default configuration as simple and minimal as possible for standard use-cases.
Related issues
No response
Are you willing to submit a PR?
- [ ] Yes I am willing to submit a PR!
Most users shouldn't have to specify any rayStartParams at all.
If that's optional, are there minimum configs to make Ray start up work? If so, we can append args on behalf of users.
Consider always adding --block
Agree. Bytedance enable it by default in downstream version.
Make serviceType optional. Default to ClusterIP
Agree. Additionally, we added these fields in CRD in the past. We are considering to move these fields to annotation instead.
If that's optional, are there minimum configs to make Ray start up work? If so, we can append args on behalf of users?
Besides what we already do, it may just be --block. We should double-check.
cc @kevin85421 @sihanwang41 on the entry-point issues Link to the discussion: https://ray-distributed.slack.com/archives/C02GFQ82JPM/p1669647595429959
https://github.com/ray-project/kuberay/issues/861 If we plan to make any API changes (remove any unhelpful fields), clean up is a breaking change and let's support multi version in beta version.
The last TODO is https://github.com/ray-project/kuberay/issues/976. Close this issue.
