[receiver/k8sobjects] Improve handling of response code 410 #24903
Assignees
Labels
Comments
TylerHelmuth
added
enhancement
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
Pinging code owners for receiver/k8sobjects: @dmitryax @hvaghani221. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
I have started working on this. |
TylerHelmuth
added a commit
that referenced
this issue
Sep 11, 2023
) **Description:** Updates the receiver to properly handle 410 response code. The expectations for what clients should do when a 410 is received can be found here: https://kubernetes.io/docs/reference/using-api/api-concepts/#410-gone-responses. I originally implemented this feature directly in `startWatch`, rebuilding the watcher and res channel within the for loop, but I grew concerned about making sure everything stopped correctly. I took a look at the retry watcher's implementation and reused its concepts for this implementation. If it is overcomplicated we can go back to my original idea. **Link to tracking Issue:** <Issue number if applicable> Closes #24903 **Testing:** <Describe what testing was performed and which tests were added.> Tested locally. Unit tests proved to be extremely challenging since I couldn't figure out how to get the mock to produce a 410. We really need e2e tests (#18395). --------- Co-authored-by: Evan Bradley <[email protected]>
gantrior
pushed a commit
to gantrior/solarwinds-otel-collector
that referenced
this issue
Feb 27, 2025
…098) **Description:** Updates the receiver to properly handle 410 response code. The expectations for what clients should do when a 410 is received can be found here: https://kubernetes.io/docs/reference/using-api/api-concepts/#410-gone-responses. I originally implemented this feature directly in `startWatch`, rebuilding the watcher and res channel within the for loop, but I grew concerned about making sure everything stopped correctly. I took a look at the retry watcher's implementation and reused its concepts for this implementation. If it is overcomplicated we can go back to my original idea. **Link to tracking Issue:** <Issue number if applicable> Closes open-telemetry/opentelemetry-collector-contrib#24903 **Testing:** <Describe what testing was performed and which tests were added.> Tested locally. Unit tests proved to be extremely challenging since I couldn't figure out how to get the mock to produce a 410. We really need e2e tests (open-telemetry/opentelemetry-collector-contrib#18395). --------- Co-authored-by: Evan Bradley <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
No response
Is your feature request related to a problem? Please describe.
The
watchcapability of the K8s API will return an http status code of 410 and a status object if the resourceVersion supplied to the API is too old. At the moment the receiver handles these situations by logging that they occurred and then stopping the watch for the object in question.This situation is most likely to occur if a user passes in a
resource_versionitself, but could occur during normal option as well (although that would be strange).Describe the solution you'd like
Instead of giving up, the receiver could do a new
Listto get a newresourceVersion. See https://kubernetes.io/docs/reference/using-api/api-concepts/#410-gone-responses for details.The text was updated successfully, but these errors were encountered: