-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Old RayServices not deleted after operator update to 1.2.1 #2374
Comments
To clarify, do you mean old RayService or Service? |
Yes, I meant the old RayService |
I don't think upgrading kuberay to v1.2.1 is suppose to delete exist RayService objects. Can you share a link to code or documentation that implies that we do this? |
Or are you referring to the "old" RayCluster used for the RayService? |
Yes, the old cluster being used for the RayService is not being deleted. |
I believe that's expected, if you upgrade kuberay without changing any fields of the RayService, the RayCluster should be not replaced |
Oh, we also made another change to the resources, specifically the amount of memory the headGroup requests. Could it be because both happened around the same time something went wrong? |
Yes, if you change some property of the RayService, it will trigger a replacement of the RayCluster. However, this doesn't apply for all fields like |
Search before asking
KubeRay Component
ray-operator
What happened + What you expected to happen
After kuberay operator update to 1.2.1 new ray services were created and are up and running as expected. But, the old ray services never got deleted. The expected behavior is for the old services to be torn down once the new ones are up but it did not happen.
Reproduction script
Following instructions from https://docs.ray.io/en/latest/cluster/kubernetes/user-guides/upgrade-guide.html to upgrade the operator to 1.2.1
^ is a message in the logs but the old cluster exists and is still dangling.
Anything else
No response
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: