fix!: Make default queue names service variant specific. - #28066
Merged
Conversation
Contributor
Author
|
jenkins run js |
2 tasks
Contributor
Author
|
This should supersede https://github.com/edx/edx-platform/pull/28065 |
jinder1s
approved these changes
Jun 30, 2021
common.py has queue names that always get overridden by production.py and lead to confusion. Set a default SERVICE_VANIANT in common.py and then set the queue names based on that in common.py so that production.py doesn't make it more complicated. This should prevent the issue where if you copy a queue name in common.py it ends up being incorrect in the production system. This is what happened with the sample_task change. https://github.com/edx/edx-platform/pull/23731 made it so that the queue name for that queue is independently configurable but the default was set to the value of HIGH_PRIORITY_QUEUE in common.py which is not the same as the value set in production.py leading to stale tasks that never get picked up in production. BREAKING_CHANGE: If anyone was building a different settings file on top of common, the default names in common.py are now change to be service variant specific. eg 'edx.cms.core.high' instead of 'edx.core.high'
feanil
force-pushed
the
feanil/arch-1821-alternative
branch
from
June 30, 2021 14:06
6dba902 to
c2d8488
Compare
Contributor
Author
|
jenkins run python |
|
Your PR has finished running tests. There were no failures. |
Contributor
|
EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production. |
Contributor
|
EdX Release Notice: This PR has been deployed to the production environment. |
Contributor
|
@arbrandes Could we get this cherry-picked into Thank you! |
Contributor
|
@pomegranited, if I can get a PR, yes, I'll add it to my list of PR cherry-picks to approve. Is this something useful to us, internally? (I.e., can we get somebody in the team to whip up the PR?) |
Contributor
|
Thanks @arbrandes , and yep, it's useful internally (it'll make our extended heartbeat checks succeed for lilac instances). |
pomegranited
pushed a commit
to open-craft/openedx-platform
that referenced
this pull request
Jul 22, 2021
fix!: Make default queue names service variant specific. (cherry picked from commit 4b29872)
2 tasks
Contributor
|
NVM @xitij2000 -- I'll do it as part of FAL-2076. |
Contributor
|
@pomegranited Sure. I'm still in process so not sure if I can start just yet. |
Contributor
|
No worries @xitij2000 -- https://github.com/edx/edx-platform/pull/28250 covers the issue for lilac, so no need for any action from you here. |
ghost
pushed a commit
that referenced
this pull request
Aug 4, 2021
## Description Cherry-picks https://github.com/edx/edx-platform/pull/28066 into `open-release/lilac.master`. ## Testing instructions * LMS: https://periodic-build-lilac.opencraft.hosting/ * Studio: https://studio.periodic-build-lilac.opencraft.hosting/ (Ocim Admins only) 1. Locate the Active running appserver for the [Periodic build Lilac instance](https://manage.opencraft.com/instance/28490/) via Ocim 2. Visit the Authenticated Link , and append `/heartbeat?extended` 3. Ensure that the `celery` check is passing. ## Deadline None ## Other information 1. Ordinarily, we'd be able to view the https://periodic-build-lilac.opencraft.hosting/heartbeat?extended to verify that the heartbeat checks are succeeding. However, the `forum` extended check is also failing for lilac.master (and master), and so Ocim redirects to the standard error page instead of showing the healthcheck json. The `forum` failure will be addressed by https://github.com/edx/configuration/pull/6482. ## Reviewer - [ ] @gabor-boros - [ ] @arbrandes
pomegranited
pushed a commit
to open-craft/openedx-platform
that referenced
this pull request
Sep 29, 2021
fix!: Make default queue names service variant specific. (cherry picked from commit 4b29872)
2 tasks
ghost
pushed a commit
that referenced
this pull request
Oct 13, 2021
## Description Cherry-picks https://github.com/edx/edx-platform/pull/28066 into `open-release/koa.master`. ## Testing instructions * LMS: https://periodic-build-koa.opencraft.hosting/ * Studio: https://studio.periodic-build-koa.opencraft.hosting/ (Ocim Admins only) 1. Visit https://periodic-build-koa.opencraft.hosting/heartbeat?extended 2. Ensure that the `celery` check is passing. 3. Shell into the latest deployed instance and run: ``` # LMS $ /edx/bin/edxapp-shell-lms >>> from django.conf import settings >>> settings.HEARTBEAT_CELERY_ROUTING_KEY 'edx.lms.core.high' >>> settings.HIGH_PRIORITY_QUEUE 'edx.lms.core.high' >>> settings.CELERY_QUEUES {'edx.lms.core.default': {}, 'edx.lms.core.high': {}, 'edx.lms.core.high_mem': {}, 'edx.cms.core.default': {}} >>> assert settings.HEARTBEAT_CELERY_ROUTING_KEY in settings.CELERY_QUEUES >>> # Studio $ /edx/bin/edxapp-shell-cms >>> from django.conf import settings >>> settings.HEARTBEAT_CELERY_ROUTING_KEY 'edx.cms.core.high' >>> settings.HIGH_PRIORITY_QUEUE 'edx.cms.core.high' >>> settings.CELERY_QUEUES {'edx.cms.core.default': {}, 'edx.cms.core.high': {}, 'edx.lms.core.default': {}} >>> assert settings.HEARTBEAT_CELERY_ROUTING_KEY in settings.CELERY_QUEUES >>> ``` ## Deadline None ## Review - [ ] @gabor-boros - [x] @arbrandes or @Agrendalath ? CC @bradenmacdonald
fsologureng
pushed a commit
to eol-uchile/openedx-platform
that referenced
this pull request
Dec 13, 2023
fix!: Make default queue names service variant specific. (cherry picked from commit 4b29872)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
common.py has queue names that always get overridden by production.py
and lead to confusion. Set a default SERVICE_VANIANT in common.py and
then set the queue names based on that in common.py so that
production.py doesn't make it more complicated.
This should prevent the issue where if you copy a queue name in
common.py it ends up being incorrect in the production system. This is
what happened with the sample_task change.
https://github.com/edx/edx-platform/pull/23731 made it so that the queue
name for that queue is independently configurable but the default was
set to the value of HIGH_PRIORITY_QUEUE in common.py which is not the
same as the value set in production.py leading to stale tasks that never
get picked up in production.
Supporting information
Jira: https://openedx.atlassian.net/browse/ARCHBOM-1821
Ticket Summary: Please investigate why sample_task tasks are stuck in a edx.core.high queue.
Deadline
None
Testing Instructions
expired)