Skip to content

feat(ray): support ReusePolicy — run Ray tasks on shared, reusable RayClusters - #1308

Merged
cosmicBboy merged 14 commits into
mainfrom
kevin/fastray
Jul 24, 2026
Merged

feat(ray): support ReusePolicy — run Ray tasks on shared, reusable RayClusters#1308
cosmicBboy merged 14 commits into
mainfrom
kevin/fastray

Conversation

@pingsutw

@pingsutw pingsutw commented Jul 16, 2026

Copy link
Copy Markdown
Member

Why

ReusePolicy today only supports container/pod tasks (reusable actors). Ray tasks always pay full RayCluster cold-start cost on every run, even when many runs share an identical cluster spec.

This PR lets users opt a Ray task environment into a shared, reusable RayCluster:

ray_env = flyte.TaskEnvironment(
    name="ray_env",
    plugin_config=RayJobConfig(...),
    reusable=flyte.ReusePolicy(replicas=1, idle_ttl=600),
)

What changed

Core stays plugin-agnostic, and the task type is unchanged — reuse is signaled through the task's custom spec:

  • Core: plugins opt in to reuse via a supports_reuse_policy class attribute (checked by the TaskEnvironment reusable+plugin_config guard) and an apply_reuse_policy(task_template) hook that task serialization dispatches to instead of add_reusable. No Ray knowledge in reuse.py.
  • Ray plugin: validates the policy (replicas maps to the number of shared clusters; only 1 supported for now, otherwise BadConfiguration) and records it under a reusePolicy key in the task's custom (RayJob) spec. The field is unknown to the RayJob proto and ignored by its unmarshalling — the task type stays ray, so backends without shared-cluster support simply run the task as a normal ephemeral Ray job.
  • Backends with shared-cluster support route on the presence of reusePolicy: shared RayCluster (keyed by the Ray spec hash, so identical specs reuse one cluster) when present, ephemeral otherwise. The generic backend plugin interface lives in feat: add ClusterPlugin interface for shared-cluster plugins flyte#7460.
  • Example: examples/plugins/ray_reusable_cluster.py.

Tests

  • tests/flyte/internal/runtime/test_reuse.py — core behavior unchanged (9 passing).
  • plugins/ray/tests/test_task.py — policy recorded in custom with type unchanged; multi-replica rejection (9 passing).

pingsutw added 2 commits July 15, 2026 11:08
A ray task with reusable=ReusePolicy(...) is retyped to fastray so the
backend runs it on a shared, reusable RayCluster instead of an ephemeral
one. replicas maps to the number of shared clusters; only replicas=1 is
supported for now and anything else raises BadConfiguration. Other plugin
task types still reject ReusePolicy.

Signed-off-by: Kevin Su <pingsutw@apache.org>
Ray is the only plugin with a reusable backend (a shared RayCluster);
other plugin tasks still reject ReusePolicy.

Signed-off-by: Kevin Su <pingsutw@apache.org>
@pingsutw pingsutw self-assigned this Jul 16, 2026
@pingsutw
pingsutw marked this pull request as draft July 16, 2026 00:51
pingsutw added 2 commits July 15, 2026 17:59
… into the ray plugin

Core no longer special-cases Ray. Plugins opt in to reuse with a
supports_reuse_policy class attribute (checked by the TaskEnvironment
guard) and an apply_reuse_policy(task_template) hook that task
serialization dispatches to instead of add_reusable.

The ray plugin implements both: it validates that the policy requests
exactly one replica (one shared RayCluster) and retypes the task to
fastray for the shared-cluster backend plugin, leaving the Ray custom
spec untouched.

Signed-off-by: Kevin Su <pingsutw@apache.org>
…e change

Drop the fastray retype: the task type stays "ray", and
apply_reuse_policy records the validated policy under a reusePolicy key
in the task's custom (RayJob) spec. The field is unknown to the RayJob
proto and ignored by its unmarshalling; backends that support shared
RayClusters route on its presence, and everything else runs the task as
a plain ephemeral ray job.

Signed-off-by: Kevin Su <pingsutw@apache.org>
@pingsutw pingsutw changed the title feat(reuse): support ReusePolicy on Ray task environments (fastray) feat(ray): support ReusePolicy — run Ray tasks on shared, reusable RayClusters Jul 16, 2026
pingsutw added 7 commits July 15, 2026 18:43
Drop the apply_reuse_policy hook; the ray plugin now records the reuse
policy directly in the RayJob custom spec, using the same field names as
the actor (fast-task) reuse spec so the backend can share its parsing.
task_serde skips the default fast-task retyping when the plugin class
sets supports_reuse_policy.

Claude-Session: https://claude.ai/code/session_01XuokhQkvv6UzxfSYrLpMTr
Signed-off-by: Kevin Su <pingsutw@apache.org>
…worker scaling

min_replica_count/replica_count scale the shared cluster's worker groups
and scaledown_ttl becomes the Ray autoscaler idle timeout, so multiple
replicas are meaningful and allowed.

Signed-off-by: Kevin Su <pingsutw@apache.org>
replicas means the number of shared RayClusters (only 1 supported) and
idle_ttl means shutting down the entire idle cluster; worker scaling
stays under the Ray plugin config, not the reuse policy.

Signed-off-by: Kevin Su <pingsutw@apache.org>
concurrency and scaledown_ttl have no meaning for a shared RayCluster —
Ray schedules work on resource availability and worker scaling belongs
to RayJobConfig. Raise BadConfiguration for non-default values instead
of silently ignoring them. (The dataclass defaults are indistinguishable
from explicitly passed defaults, so those pass.)

Signed-off-by: Kevin Su <pingsutw@apache.org>
Signed-off-by: Kevin Su <pingsutw@apache.org>
Signed-off-by: Kevin Su <pingsutw@apache.org>
@pingsutw
pingsutw marked this pull request as ready for review July 20, 2026 17:06
pingsutw added 3 commits July 20, 2026 14:04
Signed-off-by: Kevin Su <pingsutw@apache.org>
Signed-off-by: Kevin Su <pingsutw@apache.org>
@cosmicBboy
cosmicBboy merged commit fbcd852 into main Jul 24, 2026
53 checks passed
@cosmicBboy
cosmicBboy deleted the kevin/fastray branch July 24, 2026 22:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants