kuberay
kuberay copied to clipboard
[Refactor][RayCluster] RayClusterHeadPodsAssociationOptions and RayClusterWorkerPodsAssociationOptions
Why are these changes needed?
Introduce the following association functions to centralize many ad-hoc MatchingLabels that are scattered around:
- RayClusterHeadPodsAssociationOptions
- RayClusterWorkerPodsAssociationOptions
- RayClusterGroupPodsAssociationOptions
- RayClusterAllPodsAssociationOptions
These functions return options of a new type AssociationOptions that can convert the options into either a []client.ListOption or a []client.DeleteAllOfOption so that we can use them like this:
filters := common.RayClusterWorkerPodsAssociationOptions(instance)
r.List(ctx, &corev1.Pod{}, filters.ToListOptions()...)
r.DeleteAllOf(ctx, &corev1.Pod{}, filters.ToDeleteOptions()...)
Checks
- [x] I've made sure the tests are passing.
- Testing Strategy
- [x] Unit tests
- [x] Manual tests
- [ ] This PR is not tested :(
Hi @kevin85421,
What do you think about the new AssociationOptions that allows us to convert associations to either a slice of ListOption or DeleteAllOfOption?
I'd like to have your feedback, thanks!
What do you think about the new
AssociationOptionsthat allows us to convert associations to either a slice ofListOptionorDeleteAllOfOption?
LGTM
Hi @evalaiyc98, could you also help review this?
Sure!
I've noticed that the logic used here still resembles the original approach. I believe it would be beneficial to maintain consistency with the previous refactor part. What are your thoughts on this?
https://github.com/ray-project/kuberay/blob/a87f9a6a6d8ead0ffd81dc823f2fd7f38f2af027/ray-operator/controllers/ray/suite_helpers_test.go#L206-L209