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
Bug 2010174: Fix duplicate PVs for disk by-names #292
Conversation
|
@gnufied: This pull request references Bugzilla bug 2010174, which is invalid:
Comment In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gnufied 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 |
|
/bugzilla refresh |
|
@gnufied: This pull request references Bugzilla bug 2010174, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (wduan@redhat.com), skipping review request. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
| deviceName := filepath.Base(deviceNameLocation.diskNamePath) | ||
|
|
||
| for i := range pvs { | ||
| pv := pvs[i] |
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 nit: you could use for _, pv := range pvs like you did on line 276 and avoid the extra pv := pvs[i] line. Purely optional.
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 was doing that on purpose to avoid globbering of loop variables by goroutines. I know that is not the case here, but I am trying to adopt this pattern as matter of style rather than only when needed.
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.
Ok that's fine, just caught my eye.
| if !found || name != r.runtimeConfig.Name { | ||
| continue | ||
| } | ||
| addOrUpdatePV(r.runtimeConfig, pv) |
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.
When we're populating the cache here, is it possible to get a competing addOrUpdatePV call via CreateFunc?
local-storage-operator/diskmaker/controllers/lv/reconcile.go
Lines 678 to 683 in 3defd5e
| CreateFunc: func(e event.CreateEvent, q workqueue.RateLimitingInterface) { | |
| pv, ok := e.Object.(*corev1.PersistentVolume) | |
| if ok { | |
| handlePVChange(runtimeConfig, pv, q, false) | |
| } | |
| }, |
If so, what would happen in that case? Could we end up with the same PV added twice?
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 PVs in cache are keyed by volume names, which is supposed to be a unique string cluster-wide and hence last update will win I think. For our purpose here, it won't matter I think.
|
/lgtm |
|
@gnufied: All pull requests linked via external trackers have merged: Bugzilla bug 2010174 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2010174