-
Notifications
You must be signed in to change notification settings - Fork 71
Bug 2002276: Remove oudated subscription update logic to improve resolution delay #211
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 2002276: Remove oudated subscription update logic to improve resolution delay #211
Conversation
e646ba3
to
2445f40
Compare
…(#2369) Currently, olm logic checks for upgrade in subscription via another obsolete API that is no longer in use for dependency solution. As a result, sometimes, subscriptions display `UpgradeAvailable` status but there will be no upgrades as the upgrade is not valid in the resolver. Also, the `UpgradeAvailable` status is used to trigger the new resolution even though that status is no longer a valid indicator of having a pending upgrade. This leads to unwanted upgrade delay when the obsolete API works properly. This commit will remove the code that is using this obsolete API and allow the resolution to happen when there is a subscription change. Signed-off-by: Vu Dinh <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 81e7a60bc7a62da4a469041ce89e3867e9f47fde
…ock when checking for any namespace caching errors (#2382) Signed-off-by: timflannagan <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 396b5461555c2498507b1fff20fccc3e7ae15420
2445f40
to
807c857
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dinhxuanvu 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 |
@dinhxuanvu: This pull request references Bugzilla bug 2002276, 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
Requesting review from QA contact: 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. |
/label qe-approved |
/lgtm |
@dinhxuanvu: All pull requests linked via external trackers have merged: Bugzilla bug 2002276 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. |
err := snapshot.err | ||
snapshot.m.Unlock() | ||
snapshot.m.RUnlock() |
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.
@dinhxuanvu One question, maybe I missed something, why not us use the defer
here?
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.
You wouldn't be able to use defer here as we're performing locking/unlocking operations during a for loop and the defer statement only triggers once the function finishes execution. In order to use a defer statement here, you would need to wrap the lock/unlock logic into an anonymous function:
for key, snapshot := range c.snapshots {
func() {
snapshot.m.RLock()
defer snapshot.m.RUnlock()
...
}
}
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.
@timflannagan Thanks for your clarification! I think we should make sure the RLock
can be released successfully. Actually, we met an issue: https://bugzilla.redhat.com/show_bug.cgi?id=2020486 that the status of the CatalogSource is lastObservedState: IDLE
sometimes, and I checked the logs, found the warning: level=warning msg="couldn't find service in cache"
. I guess it's related to this PR.
can we backport this to 4.9? |
…shift#211) The constraint EP uses `failureMessage`, not `message`. This is a mistake that should be corrected. Signed-off-by: Vu Dinh <[email protected]>
…shift#211) The constraint EP uses `failureMessage`, not `message`. This is a mistake that should be corrected. Signed-off-by: Vu Dinh <[email protected]> Upstream-repository: api Upstream-commit: 160240770853d11a62b3ff721b3ffed2d8edf06d
…shift#211) The constraint EP uses `failureMessage`, not `message`. This is a mistake that should be corrected. Signed-off-by: Vu Dinh <[email protected]> Upstream-repository: api Upstream-commit: 160240770853d11a62b3ff721b3ffed2d8edf06d
…shift#211) The constraint EP uses `failureMessage`, not `message`. This is a mistake that should be corrected. Signed-off-by: Vu Dinh <[email protected]> Upstream-repository: api Upstream-commit: 160240770853d11a62b3ff721b3ffed2d8edf06d
/cherry-pick release-4.7 |
@sferich888: #211 failed to apply on top of branch "release-4.7":
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. |
Currently, olm logic checks for upgrade in subscription via another
obsolete API that is no longer in use for dependency solution. As a
result, sometimes, subscriptions display UpgradeAvailable status but
there will be no upgrades as the upgrade is not valid in the resolver.
Also, the UpgradeAvailable status is used to trigger the new resolution
even though that status is no longer a valid indicator of having a pending
upgrade. This leads to unwanted upgrade delay when the obsolete API works
properly.
This commit will remove the code that is using this obsolete API and
allow the resolution to happen when there is a subscription change.
Signed-off-by: Vu Dinh [email protected]