Fix partial meta request determination logic #1322
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The accept header can have multiple clauses, but we were only supporting one. The Kubernetes metadataSharedInformerFactory generates requests with the accept header having multiple clauses, and our previous logic didn't handle them correctly, leading to thinking the request was not for partial metadata, when in fact it was supposed to be. Signed-off-by: Andy Goldstein <[email protected]>
openshift-ci
bot
added
the
approved
|
/lgtm |
|
/retest |
|
e2e-shared-server failure is #1324 |
|
Hit #1324 again |
stevekuznetsov
approved these changes
Jun 21, 2022
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
|
This PR introduces a weird bug with APIBinding deletion & finalizers on CRs. |
|
/unhold |
openshift-ci
bot
removed
the
do-not-merge/hold
|
@stevekuznetsov ready for another review |
Fixing isPartialMetadataRequest led to the discovery of a bug in the apiBindingAwareCRDLister's Get() method. The apibinding deletor uses the partial metadata client to list resources to check for remaining data (i.e. CRs with finalizers). Without the fix to isPartialMetadataRequest, the metadata client was sending an Accept header that led us to say it was *not* a partial metadata request. As such, the apiBindingAwareCRDLister would proceed to getForFullData when looking up a CRD, meaning it would find a CRD via an APIBinding, which is what we want in this case. With the fix, however, now the deletor's metadata client requests are correctly interpreted as partial metadata requests. The apiBindingAwareCRDLister's logic was finding the first CRD matching the group and resource, which is less and less likely to find the correct CRD as the number of workspaces, bindings, and CRDs grows. The solution is to update the special handling of partial metadata requests when trying to get the correct CRD. We want to handle the following cases (in order of priority): 1. System CRD 2. CRD via identity (which could be for a specific cluster, or wildcard - doesn't matter) 3. Wildcard a. For partial metadata b. Non partial metadata 4. In a specific cluster - check APIBindings first, then local CRDs Signed-off-by: Andy Goldstein <[email protected]>
ncdc
force-pushed
the
fix-partial-metadata-check
branch
from
b9374b4 to
28d0d2b
Compare
stevekuznetsov
approved these changes
Jun 21, 2022
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ncdc, stevekuznetsov 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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The accept header can have multiple clauses, but we were only supporting
one. The Kubernetes metadataSharedInformerFactory generates requests
with the accept header having multiple clauses, and our previous logic
didn't handle them correctly, leading to thinking the request was not
for partial metadata, when in fact it was supposed to be.
Related issue(s)
Discovered while working on #1061