docs: updated self reporting progress example to use WorkflowTaskResults instead of Pod annotations
#12089
Conversation
…ions Signed-off-by: Nagy Attila Gabor <[email protected]>
| every 1m. | ||
|
|
||
| These values cane be fine tuned with the `ARGO_PROGRESS_PATCH_TICK_DURATION` and `ARGO_PROGRESS_FILE_TICK_DURATION` | ||
| environment variables. | ||
|
|
||
| Initially the progress of a workflows' pod is always `0/1`. If you want to influence this, make sure to set an initial | ||
| progress annotation on the pod: |
There was a problem hiding this comment.
here and on line 39 above, "pod annotations" are specifically mentioned. those should be altered as well if we will not be recommending those
There was a problem hiding this comment.
@agilgur5 I'm new to argo workflow, so I'm might not the best person to explain the process. If I understand correctly now the executor is picking up the progress and patches that to the workflowtaskresults resource. Then the controller will pick up the values from there. Am I right?
If you can suggest a new explanation for lines 38-39, I would be very glad.
Thank you
There was a problem hiding this comment.
I believe your understanding is correct. I'm not an expert in the Executor code yet either actually.
Based on your analysis in the PR description, it sounds like workflows.argoproj.io/progress is buggy and actually needs a bugfix for 3.4 to update/initialize workflowtaskresults instead of patching the pod.
There was a problem hiding this comment.
I'm not sure if it's a bug or just some conflict between the old and new behavior that could be avoided by proper configuration on the user side.
My experience on v3.5 showed that the executor automatically falls back to patching the pod resource if it has no permission to patch the workflowtaskresults, and issues a warning about this.
Meanwhile the controller looks at the pod annotations, and if finds the workflows.argoproj.io/progress annotation then the values found in there will override the values from workflowtaskresults, and issues the warning workflow uses legacy/insecure pod patch, see https://argoproj.github.io/argo-workflows/workflow-rbac/
By following the current documentation I easily navigated me into this situation where the executor was running the new behavior while the controller expecting the old one.
My goal with this PR is to help others to avoid the mistake I have made.
I have updated the explanation of the process to match the "new" method, please review it.
Co-authored-by: Anton Gilgur <[email protected]> Signed-off-by: Nagy Attila Gábor <[email protected]>
Co-authored-by: Anton Gilgur <[email protected]> Signed-off-by: Nagy Attila Gábor <[email protected]>
Signed-off-by: Nagy Attila Gabor <[email protected]>
| The controller picks this up and writes the progress to the appropriate Status properties. | ||
| patch the matching `WorkflowTaskResults` resource with the value `N/M`. | ||
| The controller picks this up and writes the progress to the appropriate Status properties | ||
| every 1m. |
There was a problem hiding this comment.
Thanks for this change. It looks like it's both patching annotations and patching WorkflowTaskResults with this progress information, right?
There was a problem hiding this comment.
Ahh, you're right. I looked at the code too quickly. The Pod Annotations are a backup, as you mention in your other comment.
| every 1m. | ||
|
|
||
| These values can be fine tuned with the `ARGO_PROGRESS_PATCH_TICK_DURATION` and `ARGO_PROGRESS_FILE_TICK_DURATION` | ||
| [environment variables](environment-variables.md). |
There was a problem hiding this comment.
even better if maybe we can clarify what those values represent?
agilgur5
changed the title
WorkflowTaskResults instead of Pod annotations
This is a proposed update to the self reporting progress documentation at https://argoproj.github.io/argo-workflows/progress/
The current example is not recommended with version >= 3.4 because the pod metadata has been superseded by the workflowtaskresults resource.
With recent versions if you add the
workflows.argoproj.io/progressannotation on the pod the controller will fall back to thelegacy mode. Also the annotation will revert the output of the executor and the progress does not change during the workflow run.
I have also included some hints how the progress update works, because it took me a while to figure out why it takes so long
for the progress to appear on the UI.
I have tested the original and the updated example on argo workflows version 3.5.0