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

Introduce usage of redbeat celery task scheduler #393

Merged
merged 2 commits into from
Dec 5, 2023
Merged

Conversation

Elkasitu
Copy link
Contributor

@Elkasitu Elkasitu commented Dec 1, 2023

This commit adds celery-redbeat as a dependency of the project and sets it as the default scheduler for celery tasks.

Unlike celery-beat, redbeat uses a Redis instance for keeping track of task schedules and uses a distributed mutex lock in order to ensure that only one instance of the scheduler can actually schedule tasks.

This comes with the following benefits:

  • The scheduler can have high availability without compromising scheduling, meaning that we can have e.g. 3 pods of the scheduler running but only one will be actively doing work at any given time, if two Availability Zones happen to go down, the remaining pod will pick up the slack.
  • The schedule is stored in Redis, meaning that even if there are scheduler restarts, the work to be done can be picked up immediately without delays.
  • Tasks can be dynamically created/modified.
  • Faster startup.

This commit also simplifies the way that the celery-beat scripts work.

Closes OSIDB-1524

@Elkasitu Elkasitu added the technical For PRs that introduce changes not worthy of a CHANGELOG entry label Dec 1, 2023
@Elkasitu Elkasitu requested a review from a team December 1, 2023 15:24
Adrian Torres added 2 commits December 1, 2023 17:01
This commit adds celery-redbeat as a dependency of the project and sets
it as the default scheduler for celery tasks.

Unlike celery-beat, redbeat uses a Redis instance for keeping track of
task schedules and uses a distributed mutex lock in order to ensure that
only one instance of the scheduler can actually schedule tasks.

This comes with the following benefits:

* The scheduler can have high availability without compromising
  scheduling, meaning that we can have e.g. 3 pods of the scheduler
  running but only one will be actively doing work at any given time, if
  two Availability Zones happen to go down, the remaining pod will pick
  up the slack.
* The schedule is stored in Redis, meaning that even if there are
  scheduler restarts, the work to be done can be picked up immediately
  without delays.
* Tasks can be dynamically created/modified.
* Faster startup.

This commit also simplifies the way that the celery-beat scripts work.

Closes OSIDB-1524
Copy link
Contributor

@osoukup osoukup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the detailed explanation! Makes sense to me and LGTM


rm -f /tmp/celery_beat.pid
exec celery -A config beat
# Reuse existing standalone version
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was the healthy check removed? I don't see it in the standalone version either.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary, the celery pods should be able to run independently of the web service as they don't depend on it.

@Elkasitu Elkasitu added this pull request to the merge queue Dec 5, 2023
Merged via the queue into master with commit 7a4bd1c Dec 5, 2023
10 checks passed
@Elkasitu Elkasitu deleted the better-scheduler branch December 5, 2023 13:31
github-merge-queue bot pushed a commit that referenced this pull request Dec 7, 2023
This PR fixes an error while creating a local venv due to a bug in pip.
It is also a follow-up to the second commit in #393.
For more info, see pypa/pip#9644.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
technical For PRs that introduce changes not worthy of a CHANGELOG entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants