Remove ray-cluster.without-block.yaml

[kevin85421]

Why are these changes needed?

We did not encourage users to run ray start without --block.

1. Without --block, we need to append sleep infinity to the end of the ray start command to keep the container running.
2. With --block, when the ray process crashes, the KubeRay operator can detect the unhealthy condition in a short time because the container will exit immediately. Without --block, the unhealthy condition can still be detected by both readiness and liveness probes, but it may take more time to detect it.

Note for those who are still interested in ray-cluster.without-block.yaml

There are two bugs in ray-cluster.without-block.yaml detected by the configuration test framework #605. See the change of ray-cluster.without-block.yaml in kevin85421@04bdd77 to fix the bugs.

• object-manager-port, node-manager-port: Update ray-operator documentation and image version in ray-cluster.heterogeneous.yaml #585

• command / args: The original YAML file assumes that command and args will be appended after the ray start command. However, the command and args will be executed before the ray start command (See [Feature][Docs] Explain how to specify container command for head pod #651 for more details.). That is, the YAML tries to connect to the Ray cluster before starting the ray cluster.

Related issue number

Checks

• I've made sure the tests are passing.
• Testing Strategy
  • Unit tests
  • Manual tests
  • This PR is not tested :(

[kevin85421]

1. Without --block, we need to append sleep infinity to the end of the ray start command to keep the container running.
2. With --block, when the ray process crashes, the KubeRay operator can detect the unhealthy condition in a short time because the container will exit immediately. Without --block, the unhealthy condition can still be detected by both readiness and liveness probes, but it may take more time to detect it.

@DmitriGekhtman Hope to double-check whether I have any misunderstanding about the reasons why we did not encourage users to run ray start without --block. Thank you!

[DmitriGekhtman]

Your understanding is correct.
We prefer to separate the process of deploying a Ray cluster (kubectl apply -f raycluster.yaml) and submitting work (e.g. ray job submit stuff.py)

For users who need custom entry-points, we had another discussion. The conclusion was that custom entrypoints should be supported in the obvious way (if an entrypoint is specified, honor it, otherwise format the relevant ray start command).

[kevin85421]

Your understanding is correct. We prefer to separate the process of deploying a Ray cluster (kubectl apply -f raycluster.yaml) and submitting work (e.g. ray job submit stuff.py)

For users who need custom entry-points, we had another discussion. The conclusion was that custom entrypoints should be supported in the obvious way (if an entrypoint is specified, honor it, otherwise format the relevant ray start command).

Got it. Thank you!

[DmitriGekhtman]

Later, we can consider inject the "block" automatically.