-
-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Good practices - updating state upon retrying #1039
Comments
I'm probably missing something, but why not just do this? @kopf.on.update('httprequests', retries=3, backoff=10)
def handler(memo: kopf.Memo, spec, name, namespace, logger, **kwargs):
r = requests.request(some_url)
if r.status_code == 500:
raise kopf.TemporaryError(f"Resource at {some_url} returns {r.status_code}", delay=60) |
That does not update status field. |
There is the Manually patching the resource is also a right way to go, there is nothing wrong with it (except for one extremely rare edge case under high load, which will be fixed soon). The only downside is that you will have 2 patch api calls: one from you, one from kopf; and you will also have to authenticate somehow not with kopf’s login machinery. |
@nolar @kopf.on.update('httprequests', retries=3, backoff=10)
def handler(memo: kopf.Memo, spec, name, namespace, logger, **kwargs):
r = requests.request(some_url)
if r.status_code == 500:
kwargs['patch'] = {
'status': {
'handler': {
'httpStatusCode': 500
}
}
}
raise kopf.TemporaryError(f"Resource at {some_url} returns {r.status_code}", delay=60) is it the right way to do? I am asking, because following snippet does not work. |
The right way. But in your case, you override the kwarg key in the local dict, you do not modify the object itself. Try this: def …(…, patch, **kwargs):
patch.status.setdefault('handler', {})['httpStatusCode'] = 500 |
Perfect, it works. Thanks for the guidance. Closing/ |
Keywords
retries, patching, state
Problem
https://kopf.readthedocs.io/en/stable/errors/#
kopf retries upon exception, if the exception is raised then the handler fails fast without returning, hence I can't update custom resource status
real-life example
my custom resource represence a HTTP request
I want to retry upon 5xx and timeouts using kopf build-int handlers retry logic
I can manually patch the resource and luckily it does not trigger on_update handler, but it does not seem like the right thing to do. For instance its not automatically logged via handler built-in logger.
The text was updated successfully, but these errors were encountered: