Andrew Sy Kim

Hmmm.. I don't see why that issue would exist. Let's wait for @ryanaoleary to update the PR based on our latest discussion and hopefully reviewing the code will make it...

> Would you mind helping me understand why you don't like ask users to specify rayStartParams directly? It is much safer and better UX. We are still documenting how to...

From discussion with @Future-Outlier and @rueian: Using rayStartParams is not a full-proof solution for autoscaling because labels from rayStartParams can be read from file `--labels-file` or values of the labels...

Agreed with everything @edoakes said, the level of complexity is pretty low and it's not a one way door. If it helps address some concerns from others, we can also...

The "Downloading file" logs seem pretty noisy. Can we only log it once per node? ``` Downloading files for node ... ```

Having both policies probably makes sense. I'm in favor of a new policy like `DeleteWorkersOnFailure`. Would it be too verbose to name it something like `DeleteClusterOnSuccessOrWorkersOnFailure`?

`DeleteWorkersOnFailure` is probably fine as long as the deletion policy on success is well documented in the API or documentation

> On second thought, I realized that users may have more combinations. For example, > > DeleteCluster on success, DeleteNone on failure > DeleteSelf on success, DeleteNone on failure >...

We can consider an API like this as well: ``` spec: deletionPolicy: onSuccess: DeleteCluster onFailure: DeleteWorkers ```