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
I had searched in the issues and found no similar feature requirement.
Description
Ray 1.3+ spills objects to external storage once the object store is full - https://docs.ray.io/en/latest/ray-core/objects/object-spilling.html. This is especially important when Ray datasets are used, as they extensively use object store. In the case of KubeRay, by default, a minimal local disk is mapped. Fortunately, object spilling can be enabled to a specific directory or S3. Spilling to S3, although an option, can be quite slow, so spilling to disk is a better option and can be done through the volume mount and configuring spilling to a specified directory (via RayStartParameters).
Kubernetes provides 3 options for mapping disk to a pod:
Using PVCs. This is probably the most general solution.
Use case
Object spilling is a prominent use case, but other options of mapping additional storage for execution can be quite useful
Related issues
The issue with PVC with Pods is that a separate PVC has to be created explicitly for every pod and only then it can be used by the pod, referencing it by name. The two options are to pass an operator a list of PVCs that are defined outside or create PVC with appropriate parameters as part of the pod creation. The first option seems to be very error-prone and I think that the second one is a by far better solution
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
Description
Ray 1.3+ spills objects to external storage once the object store is full - https://docs.ray.io/en/latest/ray-core/objects/object-spilling.html. This is especially important when Ray datasets are used, as they extensively use object store. In the case of KubeRay, by default, a minimal local disk is mapped. Fortunately, object spilling can be enabled to a specific directory or S3. Spilling to S3, although an option, can be quite slow, so spilling to disk is a better option and can be done through the volume mount and configuring spilling to a specified directory (via RayStartParameters).
Kubernetes provides 3 options for mapping disk to a pod:
Use case
Object spilling is a prominent use case, but other options of mapping additional storage for execution can be quite useful
Related issues
The issue with PVC with Pods is that a separate PVC has to be created explicitly for every pod and only then it can be used by the pod, referencing it by name. The two options are to pass an operator a list of PVCs that are defined outside or create PVC with appropriate parameters as part of the pod creation. The first option seems to be very error-prone and I think that the second one is a by far better solution
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: