-
Notifications
You must be signed in to change notification settings - Fork 34
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
Scheduler Failure Policy #66
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
Signed-off-by: joshvanl <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 - I really like this addition, it is definitely needed. It will make the system more resilient and robust. I wonder if it might make sense to have a global scope people could set for all jobs rather than on a per job basis? Or even a per job type setting? Might be interesting and less granular than a per job basis. Just something I thought of that could be an add on to this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 lgtm, just a question on defaults/where a policy is unset
Co-authored-by: Mike Nguyen <[email protected]> Signed-off-by: Josh van Leeuwen <[email protected]>
Signed-off-by: joshvanl <[email protected]>
+1 binding |
1 similar comment
+1 binding |
Based of dapr/proposals#66 Adds a `FailurePolicy` option to the `Job` API to allow re-triggering job which are marked as failed by the caller. Adds two types of policy; `Drop` and `Constant`. `Drop` has no retry policy, `Constant` will constantly retry the job trigger for a configurable delay, up to a configurable maximum number of retries (which could be infinite). Note that the failure policy retry cadence has no effect on the actual Job schedule, meaning if a job was to be retired and eventually succeeded, the Job would continue to trigger at the origin configured schedule. By default, all Jobs will have a `Constant` policy with a delay of 1s. Signed-off-by: joshvanl <[email protected]>
Based of dapr/proposals#66 Adds a `FailurePolicy` option to the `Job` API to allow re-triggering job which are marked as failed by the caller. Adds two types of policy; `Drop` and `Constant`. `Drop` has no retry policy, `Constant` will constantly retry the job trigger for a configurable delay, up to a configurable maximum number of retries (which could be infinite). Note that the failure policy retry cadence has no effect on the actual Job schedule, meaning if a job was to be retired and eventually succeeded, the Job would continue to trigger at the origin configured schedule. By default, all Jobs will have a `Constant` policy with a delay of 1s. Signed-off-by: joshvanl <[email protected]>
* Failure Policy: Adds FailurePolicy API field to Job Based of dapr/proposals#66 Adds a `FailurePolicy` option to the `Job` API to allow re-triggering job which are marked as failed by the caller. Adds two types of policy; `Drop` and `Constant`. `Drop` has no retry policy, `Constant` will constantly retry the job trigger for a configurable delay, up to a configurable maximum number of retries (which could be infinite). Note that the failure policy retry cadence has no effect on the actual Job schedule, meaning if a job was to be retired and eventually succeeded, the Job would continue to trigger at the origin configured schedule. By default, all Jobs will have a `Constant` policy with a delay of 1s. Signed-off-by: joshvanl <[email protected]> * Linter Signed-off-by: joshvanl <[email protected]> * Rename `Constant` FailurePolicy `delay` to `interval` Signed-off-by: joshvanl <[email protected]> --------- Signed-off-by: joshvanl <[email protected]>
Based of dapr/proposals#66 Adds a `FailurePolicy` option to the `Job` API to allow re-triggering job which are marked as failed by the caller. Adds two types of policy; `Drop` and `Constant`. `Drop` has no retry policy, `Constant` will constantly retry the job trigger for a configurable delay, up to a configurable maximum number of retries (which could be infinite). Note that the failure policy retry cadence has no effect on the actual Job schedule, meaning if a job was to be retired and eventually succeeded, the Job would continue to trigger at the origin configured schedule. By default, all Jobs will have a `Constant` policy with a delay of 1s. Signed-off-by: joshvanl <[email protected]>
Based of dapr/proposals#66 Adds a `FailurePolicy` option to the `Job` API to allow re-triggering job which are marked as failed by the caller. Adds two types of policy; `Drop` and `Constant`. `Drop` has no retry policy, `Constant` will constantly retry the job trigger for a configurable delay, up to a configurable maximum number of retries (which could be infinite). Note that the failure policy retry cadence has no effect on the actual Job schedule, meaning if a job was to be retired and eventually succeeded, the Job would continue to trigger at the origin configured schedule. By default, all Jobs will have a `Constant` policy with a delay of 1s. Signed-off-by: joshvanl <[email protected]>
No description provided.