-
Notifications
You must be signed in to change notification settings - Fork 61
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
Add proper implementation of UnprepareResources in kubelet plugin #109
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.
Minor comments / questions. No blockers though.
cmd/nvidia-dra-plugin/driver.go
Outdated
@@ -114,6 +113,20 @@ func (d *driver) NodePrepareResources(ctx context.Context, req *drapbv1.NodePrep | |||
return preparedResources, nil | |||
} | |||
|
|||
func (d *driver) NodeUnprepareResources(ctx context.Context, req *drapbv1.NodeUnprepareResourcesRequest) (*drapbv1.NodeUnprepareResourcesResponse, error) { | |||
klog.Infof("NodeUnPrepareResource is called: number of claims: %d", len(req.Claims)) |
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.
klog.Infof("NodeUnPrepareResource is called: number of claims: %d", len(req.Claims)) | |
klog.Infof("NodeUnprepareResource is called: number of claims: %d", len(req.Claims)) |
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
err = d.unprepare(ctx, claim.Uid) | ||
if err != nil { | ||
return &drapbv1.NodeUnprepareResourceResponse{ | ||
Error: fmt.Sprintf("error unpreparing devices for claim %v: %v", claim.Uid, err), |
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.
Question: Should this be "devices" or "resources"?
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.
I actually think either is fine since what we end up returning on success of the prepare calls is a list of CDI devices:
&drapbv1.NodePrepareResourceResponse{CDIDevices: prepared}
850abba
to
57acdf6
Compare
Previously, we always returned SUCCESS from every call to UnprepareResources, regardless of whether we successfully unprepared the claim or not. The idea being that we would always garbage collect it later, once the claim got deallocated by the controller. This commit changes the semantics to carry out the unprepare at the point it is actually requested, returning an error if this is not possible for some reason. In the past, such errors would have been missed, and the resources could have been deallocated prematurely. Signed-off-by: Kevin Klues <[email protected]>
57acdf6
to
0f8ce59
Compare
Previously, we always returned SUCCESS from every call to UnprepareResources, regardless of whether we successfully unprepared the claim or not. The idea being that we would always garbage collect it later, once the claim got deallocated by the controller.
This commit changes the semantics to carry out the unprepare at the point it is actually requested, returning an error if this is not possible for some reason. In the past, such errors would have been missed, and the resources could have been deallocated prematurely.