-
Notifications
You must be signed in to change notification settings - Fork 183
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
[V2] fix: replicas aren't getting cleaned up during driver uninstall #1557
[V2] fix: replicas aren't getting cleaned up during driver uninstall #1557
Conversation
d115886
to
72adaed
Compare
/approve |
/hold |
72adaed
to
06b098a
Compare
06b098a
to
c19337b
Compare
c19337b
to
ba91e4f
Compare
if err == nil { | ||
var wg sync.WaitGroup | ||
errors := make([]error, len(attachments)) | ||
numErrors := uint32(0) |
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 think it would be better to communicate with channels here. errors
or result
itself could be a buffered channel that would have the result of deletion. We would then send all the errors thorough that channel and instead of wg.Wait () we can have
go func() {
wg.Wait()
close(errors )
}()
then we will loop over errors to check for any error:
for error := range errors {
// update status
}
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, I see the benefit of using a buffered channel here. Let's merge this one and I will iterate on this in a separate PR as Huichan's change has dependency on this change.
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.
Actually, we don't even need a buffered channel. The loop will read all the errors as reported until the channel is closed.
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.
Sure!
@@ -90,11 +90,11 @@ const ( | |||
pod operationRequester = "pod-controller" | |||
) | |||
|
|||
type cleanUpMode int | |||
type attachmentCleanUpMode int | |||
|
|||
const ( |
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.
np: I think it would be good to document the usage here.
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: edreed, landreasyan, sunpa93 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
What type of PR is this?
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Requirements:
Special notes for your reviewer:
Release note: