Fix bug in reflector not recovering from "Too large resource version"…#92537
Conversation
wojtek-t
added
the
priority/critical-urgent
k8s-ci-robot
added
release-note
k8s-ci-robot
added
area/apiserver
kind/api-change
There was a problem hiding this comment.
timeout error is no longer checked ?
There was a problem hiding this comment.
It's checked as part of IsTooLargeResourceVersion.
There was a problem hiding this comment.
that seems a bit strange to me... timeout reason and TooLargeResourceVersion cause seem orthogonal to me
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
|
/retest |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
There was a problem hiding this comment.
this is a little strange... why does a CauseTypeResourceVersionTooLarge always have to be a timeout?
There was a problem hiding this comment.
But this is how we create the "TooLargeResourceVersion" error.
Do you suggest dropping it and leaving it rely only on the cause?
There was a problem hiding this comment.
Actually - I played a bit more with the PR and removed this part completely. The cause type being the official type seems to be enough for the purpose of this PR and makes it easier to cherrypick.
There was a problem hiding this comment.
could this be simplified to this:
return HasStatusCause(metav1.CauseTypeResourceVersionTooLarge)There was a problem hiding this comment.
nice - didn't know about this function
There was a problem hiding this comment.
should we also continue setting the message?
There was a problem hiding this comment.
if we want to backport this, I would probably leave this method here and delegate to apierrors.IsTooLargeResourceVersion(err) in old releases, rather than remove an exported method
There was a problem hiding this comment.
"resource version is coming from the future" is confusing... consider rephrasing to something like
CauseTypeResourceVersionTooLarge is used to report that that requested resource version is newer than the data observed by the API server, so the request cannot be served.
There was a problem hiding this comment.
This makes the docs below, and the docs for setIsLastSyncResourceVersionExpired misleading, since we're setting that in cases other than for expired errors. Should we rename setIsLastSyncResourceVersionExpired to setIsLastSyncResourceVersionUnavailable or something that can make sense for both expired and toolarge errors?
wojtek-t
force-pushed
the
fix_reflector_not_making_progress
branch
from
b876884 to
f65f961
Compare
k8s-ci-robot
removed
the
lgtm
There was a problem hiding this comment.
nice - didn't know about this function
There was a problem hiding this comment.
But this is how we create the "TooLargeResourceVersion" error.
Do you suggest dropping it and leaving it rely only on the cause?
wojtek-t
force-pushed
the
fix_reflector_not_making_progress
branch
from
f65f961 to
84cb34c
Compare
wojtek-t
force-pushed
the
fix_reflector_not_making_progress
branch
from
84cb34c to
3704174
Compare
There was a problem hiding this comment.
Actually - I played a bit more with the PR and removed this part completely. The cause type being the official type seems to be enough for the purpose of this PR and makes it easier to cherrypick.
|
/retest |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, wojtek-t The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
…37-upstream-release-1.18 Automated cherry pick of #92537 upstream release 1.18
7 participants
Ref #91073
/kind bug