Unindent a few entries that needd to be unindented (#6450)#6467
Conversation
|
Thanks for the pull request, @BbrSofiane! I've created OSPR-5901 to keep track of it in JIRA, where we prioritize reviews. Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
|
@regisb I've cherry-picked the commit. |
regisb
left a comment
There was a problem hiding this comment.
note: I suggested this change but I have no idea how to check this is correct.
|
@edx-community-bot merge (please) |
|
This does not look like it's working... cc @sarina |
|
cc @nedbat |
|
Thanks for submitting this fix @BbrSofiane @regisb -- I'm going to test it with our periodic build system, first with the current lilac.master (to watch it fail), and then with this change (to make sure it fixes it). Will get it merged ASAP! |
pomegranited
left a comment
There was a problem hiding this comment.
👍 Thanks @BbrSofiane !
- I tested this
- deployed a sandbox on Ocim with
open-release/lilac.master, and watched it fail atTASK [edxapp : install single-beat to run only one celerybeat scheduler] **************************************************************************************************** fatal: [149.202.181.235]: FAILED! => { "changed": false, "msg": "Unsupported parameters for (pip) module: become_user, tags, when Supported parameters include: chdir, editable, executable, extra_args, name, requirements, state, umask, use_mirrors, version, virtualenv, virtualenv_command, virtualenv_python, virtualenv_site_packages" } - updated the sandbox to use this PR branch for deployment, and deployment passed that step without error.
- deployed a sandbox on Ocim with
- I checked the code against the original https://github.com/edx/configuration/pull/6450
|
@BbrSofiane 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
…ed#6450) (openedx-unsupported#6467) (cherry picked from commit 945fe9d) Co-authored-by: Chris Pappas <christopappas@users.noreply.github.com>
The current implementation of celerybeat usage works properly if and only if one concurrent worker process runs per queue using the nested beat process started by the `--beat` flag. In case the the celerybeat process is running as a separate process not as part of the workers, that partially solves the problem. Either in that case, if multiple instances are running in a cluster, without proper process supervising across instances will result in (at least) dumplicated scheduling, meaning that the scheduler will cause more work for the workers and results will be duplicated. Taking the above into consideration, to solve this issue, this commit introduces single-beat package that wraps the celerybeat process and keeps track of the process that acquired the lock in redis. In case one of the instances get killed or the locking process crashes, the lock refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> Unindent a few entries that needd to be unindented (openedx-unsupported#6450) (openedx-unsupported#6467) (cherry picked from commit 945fe9d) Co-authored-by: Chris Pappas <christopappas@users.noreply.github.com>
The current implementation of celerybeat usage works properly if and only if one concurrent worker process runs per queue using the nested beat process started by the `--beat` flag. In case the the celerybeat process is running as a separate process not as part of the workers, that partially solves the problem. Either in that case, if multiple instances are running in a cluster, without proper process supervising across instances will result in (at least) dumplicated scheduling, meaning that the scheduler will cause more work for the workers and results will be duplicated. Taking the above into consideration, to solve this issue, this commit introduces single-beat package that wraps the celerybeat process and keeps track of the process that acquired the lock in redis. In case one of the instances get killed or the locking process crashes, the lock refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> Unindent a few entries that needd to be unindented (openedx-unsupported#6450) (openedx-unsupported#6467) (cherry picked from commit 945fe9d) Co-authored-by: Chris Pappas <christopappas@users.noreply.github.com>
|
Thank you all! |
The current implementation of celerybeat usage works properly if and only if one concurrent worker process runs per queue using the nested beat process started by the `--beat` flag. In case the the celerybeat process is running as a separate process not as part of the workers, that partially solves the problem. Either in that case, if multiple instances are running in a cluster, without proper process supervising across instances will result in (at least) dumplicated scheduling, meaning that the scheduler will cause more work for the workers and results will be duplicated. Taking the above into consideration, to solve this issue, this commit introduces single-beat package that wraps the celerybeat process and keeps track of the process that acquired the lock in redis. In case one of the instances get killed or the locking process crashes, the lock refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> Unindent a few entries that needd to be unindented (#6450) (#6467) (cherry picked from commit 945fe9d) Co-authored-by: Chris Pappas <christopappas@users.noreply.github.com>
The current implementation of celerybeat usage works properly if and only if one concurrent worker process runs per queue using the nested beat process started by the `--beat` flag. In case the the celerybeat process is running as a separate process not as part of the workers, that partially solves the problem. Either in that case, if multiple instances are running in a cluster, without proper process supervising across instances will result in (at least) dumplicated scheduling, meaning that the scheduler will cause more work for the workers and results will be duplicated. Taking the above into consideration, to solve this issue, this commit introduces single-beat package that wraps the celerybeat process and keeps track of the process that acquired the lock in redis. In case one of the instances get killed or the locking process crashes, the lock refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> Unindent a few entries that needd to be unindented (openedx-unsupported#6450) (openedx-unsupported#6467) (cherry picked from commit 945fe9d) Co-authored-by: Chris Pappas <christopappas@users.noreply.github.com>
The current implementation of celerybeat usage works properly if and only if one concurrent worker process runs per queue using the nested beat process started by the `--beat` flag. In case the the celerybeat process is running as a separate process not as part of the workers, that partially solves the problem. Either in that case, if multiple instances are running in a cluster, without proper process supervising across instances will result in (at least) dumplicated scheduling, meaning that the scheduler will cause more work for the workers and results will be duplicated. Taking the above into consideration, to solve this issue, this commit introduces single-beat package that wraps the celerybeat process and keeps track of the process that acquired the lock in redis. In case one of the instances get killed or the locking process crashes, the lock refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> refactor: use boolean flag to enable or disable celery beat Co-authored-by: Joseph Mulloy <jdmulloy@users.noreply.github.com> Unindent a few entries that needd to be unindented (openedx-unsupported#6450) (openedx-unsupported#6467) (cherry picked from commit 945fe9d) Co-authored-by: Chris Pappas <christopappas@users.noreply.github.com>
(cherry picked from commit 945fe9d)
Configuration Pull Request
Make sure that the following steps are done before merging: