-
Notifications
You must be signed in to change notification settings - Fork 545
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 1763749: Prioritize APIs from same CatSrc #1091
Bug 1763749: Prioritize APIs from same CatSrc #1091
Conversation
Problem: When OLM installs an operator that requires dependencies that are provided via multiple operators in different CatalogSources, the API is pulled from any of the CatalogSources that provide the API. Solution: This commit introduces a change so that OLM will generate a list of operators that depend on the API, randomly select one of their sources, and prioritize checking in that CatalogSource for the API prior to checking the remaining CatalogSource for the API.
@awgreene: This pull request references Bugzilla bug 1763749, 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. |
/retest |
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 looks excellent wrt backporting the original fix! That being said, since I wasn't able to ask these questions on the original's PR, I've decided to pose them here:
// identify the initialSource | ||
initialSource := CatalogKey{} | ||
for _, operator := range e.gen.MissingAPIs()[*api] { | ||
initialSource = operator.SourceInfo().Catalog |
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.
Correct me if I'm wrong, but doesn't this break down when there exists two or more concurrent Subscriptions
that require the same API, but target different sources that contain operators providing that API?
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 are correct that the current approach can introduce some randomness when the following conditions are met:
Operator A
defines dependencies on APIs provided byOperator B
andOperator C
Operator B
andOperator C
come from differentCatalogSources
- Both
Operator B
andOperator C
define dependencies on the same API provided byOperator D
.
In this situation - the existing solution does not guarantee that a specific CatalogSource
will be prioritized consistently.
This is a known issue with the short-term solution and is expected to be addressed in a future solution. We are comfortable with supporting the existing approach due to the fact that this "bug" only hits a small number of use cases.
}, | ||
out: out{ | ||
bundle: nil, | ||
key: nil, | ||
err: fmt.Errorf("group/version/kind (plural) not provided by a package in any CatalogSource"), | ||
}, | ||
}, | ||
{ |
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.
nit: It would be nice to add descriptive names to each test case.
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.
Will do.
key: &CatalogKey{Name: "test2", Namespace: "ns"}, | ||
err: nil, | ||
}, | ||
}, |
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 we should have a test to ensure that the correct bundle is returned when more than one source containing a provider is given along with the preferred source key.
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 covered in the E2E testcase. I can create a Unit test as well.
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.
It's probably best to add it to master
.
|
||
// Create a subscription that has a dependency | ||
subscriptionName := genName("podconfig-sub-") | ||
cleanupSubscription := createSubscriptionForCatalogWithSpec(t, crClient, testNamespace, subscriptionName, subSpec) |
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.
Could we add concurrent Subscriptions
pointing to each catalog to test the aforementioned "break down"?
/retest |
/lgtm we need this in the next 4.2 and 4.1, comments can be addressed in a followup in master |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awgreene, ecordell 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 |
@Bowenislandsong: This pull request references Bugzilla bug 1763749, 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. 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. |
AWS throttled our API requests. /retest |
/retest |
Cool. /retest |
@awgreene: All pull requests linked via external trackers have merged. Bugzilla bug 1763749 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. |
/cherry-pick release-4.1 |
@awgreene: #1091 failed to apply on top of branch "release-4.1":
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. |
Problem: When OLM installs an operator that requires dependencies that
are provided via multiple operators in different CatalogSources, the API
is pulled from any of the CatalogSources that provide the API.
Solution: This commit introduces a change so that OLM will generate a
list of operators that depend on the API, randomly select one of their
sources, and prioritize checking in that CatalogSource for the API prior
to checking the remaining CatalogSource for the API.
This commit is different than the 4.3 fix because of a method signature in the e2e test.
Reviewer Checklist
/docs