Skip to content
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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

JoshVanL
Copy link
Contributor

No description provided.

Copy link
Contributor

@cicoyle cicoyle left a 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

Copy link
Member

@mikeee mikeee left a 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

20240919-scheduler-failure-policy.md Show resolved Hide resolved
Co-authored-by: Mike Nguyen <[email protected]>
Signed-off-by: Josh van Leeuwen <[email protected]>
@cicoyle cicoyle mentioned this pull request Oct 1, 2024
22 tasks
20240919-scheduler-failure-policy.md Outdated Show resolved Hide resolved
@mikeee mikeee self-requested a review October 2, 2024 15:29
@artursouza
Copy link
Member

+1 binding

1 similar comment
@yaron2
Copy link
Member

yaron2 commented Oct 3, 2024

+1 binding

JoshVanL added a commit to JoshVanL/go-etcd-cron that referenced this pull request Oct 4, 2024
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]>
JoshVanL added a commit to JoshVanL/go-etcd-cron that referenced this pull request Oct 14, 2024
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]>
artursouza pushed a commit to diagridio/go-etcd-cron that referenced this pull request Oct 14, 2024
* 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]>
JoshVanL added a commit to JoshVanL/go-etcd-cron that referenced this pull request Oct 15, 2024
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]>
JoshVanL added a commit to diagridio/go-etcd-cron that referenced this pull request Oct 15, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants