Skip to content
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

Merged

Conversation

awgreene
Copy link
Member

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

  • Implementation matches the proposed design, or proposal is updated to match implementation
  • Sufficient unit test coverage
  • Sufficient end-to-end test coverage
  • Docs updated or added to /docs
  • Commit messages sensible and descriptive

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.
@openshift-ci-robot openshift-ci-robot added the bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. label Oct 28, 2019
@openshift-ci-robot
Copy link
Collaborator

@awgreene: This pull request references Bugzilla bug 1763749, which is invalid:

  • expected dependent Bugzilla bug 1762769 to be in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), but it is ON_QA instead
  • expected dependent Bugzilla bug 1763750 to be in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), but it is NEW instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Bug 1763749: Prioritize APIs from same CatSrc

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.

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 28, 2019
@njhale
Copy link
Member

njhale commented Oct 28, 2019

/retest

Copy link
Member

@njhale njhale left a 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
Copy link
Member

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?

Copy link
Member Author

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 and Operator C
  • Operator B and Operator C come from different CatalogSources
  • Both Operator B and Operator C define dependencies on the same API provided by Operator 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"),
},
},
{
Copy link
Member

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.

Copy link
Member Author

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,
},
},
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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)
Copy link
Member

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"?

@ecordell
Copy link
Member

/retest

@ecordell
Copy link
Member

ecordell commented Oct 31, 2019

/lgtm
/approve

we need this in the next 4.2 and 4.1, comments can be addressed in a followup in master

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 31, 2019
@openshift-ci-robot
Copy link
Collaborator

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 31, 2019
@Bowenislandsong
Copy link
Member

/bugzilla refresh

@openshift-ci-robot
Copy link
Collaborator

@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:

/bugzilla refresh

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.

@openshift-ci-robot openshift-ci-robot added bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. and removed bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Oct 31, 2019
@crawford crawford added the cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. label Nov 1, 2019
@crawford
Copy link

crawford commented Nov 4, 2019

AWS throttled our API requests.

/retest

@ecordell
Copy link
Member

ecordell commented Nov 4, 2019

/retest

@crawford
Copy link

crawford commented Nov 4, 2019

error simulating policy: SerializationError: failed to decode query XML error response\n\tstatus code: 500, request id: \ncaused by: EOF

Cool.

/retest

@openshift-merge-robot openshift-merge-robot merged commit b0c1709 into operator-framework:release-4.2 Nov 5, 2019
@openshift-ci-robot
Copy link
Collaborator

@awgreene: All pull requests linked via external trackers have merged. Bugzilla bug 1763749 has been moved to the MODIFIED state.

In response to this:

Bug 1763749: Prioritize APIs from same CatSrc

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.

@awgreene
Copy link
Member Author

awgreene commented Nov 5, 2019

/cherry-pick release-4.1

@openshift-cherrypick-robot

@awgreene: #1091 failed to apply on top of branch "release-4.1":

error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M	test/e2e/subscription_e2e_test.go
A	test/e2e/user_defined_sa_test.go
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): test/e2e/user_defined_sa_test.go deleted in HEAD and modified in bug(dependencies) Prioritize APIs from same CatSrc. Version bug(dependencies) Prioritize APIs from same CatSrc of test/e2e/user_defined_sa_test.go left in tree.
Auto-merging test/e2e/subscription_e2e_test.go
CONFLICT (content): Merge conflict in test/e2e/subscription_e2e_test.go
Patch failed at 0001 bug(dependencies) Prioritize APIs from same CatSrc

In response to this:

/cherry-pick release-4.1

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants