-
Notifications
You must be signed in to change notification settings - Fork 430
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
Adding serve support for Api server #1728
base: master
Are you sure you want to change the base?
Conversation
@tedhtchang, @z103cb please take a look cc: @kevin85421 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very Nice! I was able to verify the PR following the instruction. There are some typos otherwise LGTM. Thanks
@kevin85421 its ready for you |
The CI fails consistently. Would you mind taking a look? Thanks! |
This test sometimes PASSED locally.
Sometimes failed with
or
|
ANd I do not think this PR changes anything there |
Hmm, I'm not referring to the test-rayservice-sample-yamls-latest-release. More than one CI check has failed. You may need to rebase the branch or open a new PR instead. |
1279161
to
e4c5db8
Compare
@kevin85421 we are all set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the KubeRay API server should construct its own HTTP client instead of using the existing one in KubeRay.
- The dashboard HTTP client in KubeRay is not a user-facing API, so no one promises its backward compatibility. Constructing a new one in KubeRay API server can improve the stability.
- Reducing the dependencies between KubeRay API server and KubeRay can avoid a lot of issues for users and developers. For example, KubeRay API server may want to support multiple versions of KubeRay and Ray. It is hard to achieve if there are a lot of dependencies between them.
- The fact that these functions are not used by KubeRay means they are not tested by end-to-end tests and not utilized by users. Therefore, it is difficult to ascertain whether they work or not.
- Using the dashboard HTTP client in KubeRay for communication with Ray doesn't seem to make much sense to me. The KubeRay API server can directly talk to Ray.
Sorry @kevin85421 , I completely disagree with your statements, see point-by-point replies below
|
@kevin85421, so where do we go from here. We disagree, should we ask for the third opinion? |
@kevin85421 we need to come to some kind of resolution here. Leaving it hanging is not a solution @architkulkarni ? |
6b4e022
to
900f6c2
Compare
d716d2f
to
c0553dd
Compare
12e7f45
to
daf060d
Compare
a06d2b2
to
c4bdff5
Compare
@kevin85421 it has been over a month. Any chance you can get to this? |
I will remove all functions in We have 3 possible options to clean up
|
There are 2 methods added there:
The biggest change is updating the return definition to align it with the definition of the serve implementation Do whatever you have to do. This is taking way too long |
rebased to master
@kevin85421 moved |
@kevin85421 the only change to the ray operator is in |
@@ -239,7 +239,7 @@ func DefaultWorkerPodTemplate(ctx context.Context, instance rayv1.RayCluster, wo | |||
return podTemplate | |||
} | |||
|
|||
func initLivenessAndReadinessProbe(rayContainer *corev1.Container, rayNodeType rayv1.RayNodeType, creatorCRDType utils.CRDType) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is better to avoid having the KubeRay API server call functions within KubeRay. I will only take care of the CRD compatibility, not the internal functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, here we go again. There is plenty of dependencies already. Do you really assume reproducing all of the code in the API server? This makes no sense to me, sorry. Can we, please, get a second opinion from one of your colleges?
We have been sitting on this PR for several month right now and its getting counter productive. I can do requested enhancements anymore, because we are stuck here for several month
Why are these changes needed?
Extending API server to support serve
Related issue number
Checks