-
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
Retry with node selector does not retry only specified step #11279
Comments
How to get involved in argo workflows for the contribution. |
Relevant code is here. Would anyone like to take a look? https://github.com/argoproj/argo-workflows/blob/master/workflow/util/util.go#L804 |
I think this relates to #10675 where the possible key/values for node selector are very hard to know |
@tooptoop4 Are you saying it might just be an issue with my CLI command? If so, that would be great. |
If this is indeed a bug, I may be able to justify some time toward this in the next couple of months. We're evaluating Argo Workflows right now as a DAG solution. We still have a lot of work to do toward that end, but being able to retry only specific failed nodes is a requested feature of any solution we go with. |
the trouble is we don't have an enum of available values, so we could be sending argument of |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
any luck @sstaley-hioscar ? |
So far no one's requested the feature on our end |
Seems like this has been superseded by #12543 which has had a decent bit of activity |
Pre-requisites
:latest
What happened/what you expected to happen?
when I run a workflow with two parallel steps, I can't restart only one of them. If I run, for instance,
argo retry greeter-workflow-steps-dev-vx9zf -n infra-compute --node-field-selector="id=greeter-workflow-steps-dev-vx9zf-2583895212"
all failed nodes are restarted, despite my node field selector.
Am I running the command wrong?
Version
v3.4.8
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.
we use a helm chart that adds env vars to all containers, so I can only past the "spec" portion.
or
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: