-
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
Fail suspended steps after deadline #1704
Fail suspended steps after deadline #1704
Conversation
Should we add a example or tests file? |
There's already an example with activeDeadlineSeconds, but I've added a test. |
looks like it is only working on
|
Is this not an existing problem with activeDeadlineSeconds rather than
relating to this commit? Eg if you have a pod that doesn't have a status
change rather than a suspend step then I also think the wf wouldn't be
requeued ...
…On Tue, 5 Nov 2019 at 01:25, Saravanan Balasubramanian < ***@***.***> wrote:
looks like it is only working on activeDeadlineSeconds: 0 you need to
requeue the wf to keep checking the deadlinseconds. Try the below example.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: suspend-template1
spec:
entrypoint: suspend
activeDeadlineSeconds: 5
templates:
- name: suspend
suspend: {}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1704>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABO7LSJSNTDX7ULCOTQYD3QSDDSDANCNFSM4JDTHAFA>
.
|
Yes, you are right, it is an existing issue. I can see every 10 mins fresh all WF refresh. We need to come up with some implementation like
if we have the above implementation then the controller will behave the expected behavior. |
Workflow code is already using |
474331f
to
1c62788
Compare
@sarabala1979 I have applied this to requeue suspended steps. |
Suspended steps would never time out, regardless of the setting of activeDeadlineSeconds.
This change fixes that.