kuberay
kuberay copied to clipboard
ray-project
[Feat][RayCluster] Introduce the RayClusterStatus.Conditions field
Why are these changes needed?
This is the first part of the process to refine the Ready/Failed status in RayClusterStatus https://docs.google.com/document/d/1bRL0cZa87eCX6SI7gqthN68CgmHaB6l3-vJuIse-BrY
In this first PR, we introduce the new RayClusterStatus.Conditions field, borrowed from the idea of k8s Deployment https://github.com/kubernetes/api/blob/857a946a225f212b64d42c68a7da0dc44837636f/apps/v1/types.go#L532-L542
Related issue number
Checks
- [x] I've made sure the tests are passing.
- Testing Strategy
- [x] Unit tests
- [x] Manual tests
@rueian @kevin85421 can we have the API change and implementation in the same PR if possible? Otherwise, if we release v1.2 before the implementation we'd have to revert this PR.
can we have the API change and implementation in the same PR if possible? Otherwise, if we release v1.2 before the implementation we'd have to revert this PR.
Do you mean adding HeadReady and RayClusterReplicaFailure only when we implement them? cc @andrewsykim
Do you mean adding HeadReady and RayClusterReplicaFailure only when we implement them?
Yes, and also the addition of the new conditions field in status. We should avoid changing the CRD / API until there is an working / tested minimum implementation. What do you think?
@kevin85421 on second thought, I think incremental PRs is fine as long as it's feature gated. I added initial feature gate implementation in https://github.com/ray-project/kuberay/pull/2219, what do you think?
I am ok with the feature gate or waiting for the implementation of HeadReady and RayClusterReplicaFailure.
We should avoid changing the CRD / API until there is an working / tested minimum implementation.
Hi @andrewsykim, do we still need to keep the old CRD / API if the gate is disabled? I thought that could only be achieved by introducing a new CRD version.
@andrewsykim Does #2219 need to be merged before this PR or the order is flexible?
@rueian I have synchronized with @andrewsykim today. If the feature flag is off, we will still generate conditions for the CRD, but we will not write anything to conditions. This PR doesn't write anything to conditions, so this PR is independent from #2219.