You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user creates a RayService without setting the annotation ray.io/ft-enabled: "true", but they do set RAY_REDIS_ADDRESS and REDIS_PASSWORD. As a result, the RayCluster enables GCS FT and writes data to the external Redis, but KubeRay is unaware of this. KubeRay doesn't configure RAY_external_storage_namespace so that the RayCluster writes data to the key default in the Redis.
When the user triggers a zero-downtime upgrade, the new RayCluster also attempts to read metadata from the default key in Redis. Therefore, the new RayCluster will see some information from the old RayCluster.
Solution:
Explicitly disable GCS FT if KubeRay determines that the RayCluster has not enabled GCS FT.
Reproduction script
TODO
Anything else
No response
Are you willing to submit a PR?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered:
Search before asking
KubeRay Component
ray-operator
What happened + What you expected to happen
See this Slack thread for more details.
The user creates a RayService without setting the annotation
ray.io/ft-enabled: "true"
, but they do setRAY_REDIS_ADDRESS
andREDIS_PASSWORD
. As a result, the RayCluster enables GCS FT and writes data to the external Redis, but KubeRay is unaware of this. KubeRay doesn't configureRAY_external_storage_namespace
so that the RayCluster writes data to the keydefault
in the Redis.When the user triggers a zero-downtime upgrade, the new RayCluster also attempts to read metadata from the
default
key in Redis. Therefore, the new RayCluster will see some information from the old RayCluster.Solution:
Reproduction script
TODO
Anything else
No response
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: