🐛 Fix restmapper cache invalidation when version is not provided - #3543
🐛 Fix restmapper cache invalidation when version is not provided#3543zioc wants to merge 1 commit into
Conversation
findAPIGroupByNameAndMaybeAggregatedDiscoveryLocked can't rely on the apiGroups cache, otherwise new versions of a group may never be discovered when the client does not provide a group version.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: zioc The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @zioc! |
kubernetes-prow
Bot
added
the
needs-ok-to-test
|
Hi @zioc. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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-sigs/prow repository. |
kubernetes-prow
Bot
added
size/L
| // If the server supports aggregated discovery, it will always perform that. | ||
| func (m *mapper) findAPIGroupByNameAndMaybeAggregatedDiscoveryLocked(groupName string) (_ *metav1.APIGroup, didAggregatedDiscovery bool, _ error) { | ||
| // Looking in the cache first | ||
| group, ok := m.apiGroups[groupName] |
There was a problem hiding this comment.
A patch like this essentially disables all caching, thats a pretty big regression as it results in running discovery on every single request. I don't think we are willing to accept that.
There was a problem hiding this comment.
I may misunderstood, but I was thinking that this function was only called when a cache miss previously occurred in interface methods like RESTMapping:
res, err := m.getMapper().RESTMapping(gk, versions...) // Initial cache lookup
if meta.IsNoMatchError(err) { // Cache miss
if err := m.addKnownGroupAndReload(gk.Group, versions...); err != nil { // Fetch API
return nil, err
}
res, err = m.getMapper().RESTMapping(gk, versions...)
}
And all the code paths leading to that function are following the same pattern:
client request -> IsNoMatchError (cache miss) -> addKnownGroupAndReload -> findAPIGroupByNameAndMaybeAggregatedDiscoveryLocked (when len(versions) == 0)
So I used to believe that it is was acceptable to remove this cache lookup in findAPIGroupByNameAndMaybeAggregatedDiscoveryLocked, since this code was only reached when mapping was not found in cache during first lookup. At some point, if the resource was not found in cache, and version is not provided by client, all group resources need to be fetched from the API, otherwise it will never be discovered. This is highlighted in the provided test that fails with current implementation whereas it simulates a real use-case (CRD installed after initial call to RESTMapping)
I'm open to any suggestion to implement a better fix, and I am also willing to close this PR and pass the relay if some maintainer wants to tackle the issue, but I feel that it deserves to be fixed.
|
/hold |
kubernetes-prow
Bot
added
the
do-not-merge/hold
3 participants
restmapper's
findAPIGroupByNameAndMaybeAggregatedDiscoveryLockedmethod can't rely on the apiGroups cache, otherwise new versions of a group will never be discovered when the client does not provide a group version while requesting a RESTMapping.Fixes: #3542