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.
Context
We have some problems with the
raise
interceptor that it, in conjunction with the waymartian
defines the interceptor stack, will always log the exception onstderr
.Explaining in more detail:
interceptors.raise
code will throw if there is a non 200 status.tripod
stack and will be raised to the tripod.context/execute call.The proposed solution by the developers is to catch such exceptions before, which seems to be a good option, considering that what we are doing on OUR code is to use http status as control flow and exceptions are not actually a good driver for this.
The main issue here, is that with these exceptions always being logged on
stderr
causes our monitoring to be hectic as we should keep monitoring for problems there and ignoring stack traces seems to be dangerous in this situation.Impact
I've checked the usages of the kubernetes-api.core namespace, and there does not seems to be any usage of the
:interceptor
parameter, even it being a breaking change, it will not have impact on our codebase.Changelog
:refer :all
in tests:interceptor
parameter to override all the default interceptors of the client.