-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
argo deletes persistant volume claims prematurely when parallelism is set lower than the number of items in loop #11119
Comments
I can also confirm that bug exists in We upgraded Argo Workflows from
Logs from Workflow Controller:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions. |
…11119 (#11138) Signed-off-by: Abraham Bah <[email protected]>
…rgoproj#11119 (argoproj#11138) Signed-off-by: Abraham Bah <[email protected]>
…11119 (#11138) Signed-off-by: Abraham Bah <[email protected]>
…rgoproj#11119 (argoproj#11138) Signed-off-by: Abraham Bah <[email protected]> Signed-off-by: Dillen Padhiar <[email protected]>
Pre-requisites
:latest
What happened/what you expected to happen?
Submitting a workflow looping over items in parallel using persistent volume claims causes the whole workflow to hang if workflow.spec.parallelism is set too low. Logs indicate that the workflow gets cancelled due to "max parallelism reached", which again causes the pvc's to get garbage collected. I expected argo workflow to honor the parallelism field and not launch more sub tasks than allowed by throttling execution.
Version
v3.4.7
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: