-
Notifications
You must be signed in to change notification settings - Fork 403
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
Support updating RayServices using the KubeRay API Server #633
Support updating RayServices using the KubeRay API Server #633
Conversation
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.
/cc @brucez-anyscale @simon-mo
Let's ask anyscale team to help review it and see if the PR makes sense.
@@ -67,6 +73,19 @@ message CreateRayServiceRequest { | |||
string namespace = 2; | |||
} | |||
|
|||
message UpdateRayServiceRequest { | |||
// The ray service to be updated. | |||
RayService service = 1; |
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.
why do we need entire object here? is name + namespace good enough?
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.
Updated, remove the service from the body.
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.
is service removed?
proto/serve.proto
Outdated
// The namespace of the ray service to be updated. | ||
string namespace = 3; | ||
// specify the worker group to be update | ||
repeated WorkerGroupUpdateSpec worker_group_update_spec = 4; |
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.
Seems we want to use patch mode (partial update)?
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.
How will you make sure it only find the right spec and update it? Do you plan to use name for consistency?
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.
here I would like to use patch mode, the logic in util/service.go
would check the field by workergroup name and serviceconfig name as the key and if need to modify then update it.
919d7ef
to
3bc8e57
Compare
3bc8e57
to
488e9b4
Compare
service.Spec.ServeDeploymentGraphSpec.ServeConfigSpecs = newServeConfigSpecs | ||
} | ||
|
||
newService, err := client.Update(ctx, service, metav1.UpdateOptions{}) |
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.
so if service
resourceVersion
changes, the update could fail ?
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.
we just leverage the client go's update
and it will directly put the update event to the k8s workerqueue and wait for previous resourceVersion changed?
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.
yeah, but k8s do update in a reconcile loop. So if it fails, it will retry in next loop. But this api call is 1 time call. Do we want to retry here? Or the caller should retry their side?
} | ||
} | ||
for i, spec := range workerGroupSpecs { | ||
if updateSpec, ok := specMap[spec.GroupName]; ok { |
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.
this is update logic. what if updateSpecs
has new worker groups, do we support adding new worker groups?
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.
Good question, for now if we add or delete the worker group by name, do we think it's better to add/delete or just keep the old one? I think we need to support adding/deleting worker groups. WDYT? @Jeffwan
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.
RayService should be able to handle any spec update. So here we just need a design about http request, how to support add/delete/update
apiserver/pkg/util/service.go
Outdated
} | ||
for i, spec := range serveConfigSpecs { | ||
if updateSpec, ok := specMap[spec.Name]; ok { | ||
newSpec := updateServeConfigSpec(updateSpec, spec) |
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.
the same, do we support adding service config? Also how to support deleting?
thanks for the pr. I leave some comments |
488e9b4
to
c04a75b
Compare
c04a75b
to
ac40deb
Compare
Hi @Jeffwan @brucez-anyscale I've made a new modification that support two types of APIs to update the ray service,
this might be tricky things since for now in rayservice, we just doing simple check if the raycluster spec should update, we just recreate a new one, I will create a issue to discuss this in detail. |
@brucez-anyscale if you have a spare moment to re-review this, that would be great |
it is fine. I think we can merge and improve based on it |
Support updating Ray Services using the KubeRay ApiServer. Co-authored-by: chenyu.jiang <chenyu.jiang@bytedance.com>
Why are these changes needed?
support update ray service for current apiserver.
Related issue number
Checks