Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RayJob][Status][7/n] Define JobDeploymentStatusNew explicitly #1772

Merged
merged 1 commit into from
Dec 27, 2023

Conversation

kevin85421
Copy link
Member

@kevin85421 kevin85421 commented Dec 26, 2023

Why are these changes needed?

JobDeploymentStatusNew indicates that this is a new RayJob CR, similar to NewState in the spark-on-k8s-operator.

Related issue number

Checks

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

@kevin85421 kevin85421 changed the title [RayJob][Status][7/n] [RayJob][Status][7/n] Define JobDeploymentStatusNew explicitly Dec 26, 2023
@kevin85421 kevin85421 marked this pull request as ready for review December 26, 2023 23:16
Copy link
Contributor

@architkulkarni architkulkarni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this? Maybe you can add a brief PR description.

Copy link
Contributor

@architkulkarni architkulkarni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the goal is to move all logic inside the switch statement. That sounds fine to me

@kevin85421
Copy link
Member Author

I guess the goal is to move all logic inside the switch statement. That sounds fine to me

Sorry. I have already updated the PR description. I plan to move most logic into a switch statement like syncSparkApplication in the Spark operator to build a well-defined state machine.

@kevin85421
Copy link
Member Author

CI failure is about RayService and has no relationship with RayJob.

@kevin85421 kevin85421 merged commit 59503c6 into ray-project:master Dec 27, 2023
24 of 25 checks passed
@Irvingwangjr
Copy link

Irvingwangjr commented Dec 27, 2023

I guess the goal is to move all logic inside the switch statement. That sounds fine to me

Sorry. I have already updated the PR description. I plan to move most logic into a switch statement like syncSparkApplication in the Spark operator to build a well-defined state machine.

Just out of curiosity, why do we try to use state machine here? In kubernetes, we need to deal with cache stale problem, which means the state itself might be stale and not reliable. What's more, workerQueue will squash some of the events and kuberay controller will only have one single reconcile. Those situations will make controller logic more complicated

@kevin85421
Copy link
Member Author

@Irvingwangjr Thank you for the question! Yes, there is a delay between the informer cache and the Kubernetes API server. I've built a state machine to more clearly define the state transitions. However, this does not mean that the goal state of the RayJob spec is stateful. In addition, the state transition is not determined by the resource events. The Spark operator is a mature K8s operator that supports batch job patterns. It also defines a state machine. I refer a lot from the project. You may be interested in it.

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.

None yet

3 participants