This commit "undoes"a previous hotfix, and allows a cms course_publish
signal to trigger a block_structure update_course_in_cache task, which
is run on an lms worker queue.
Changes:
-exposes ALTERNATE_QUEUE_ENVS
-adds routing layer in celery.py
-moves prior dev_with_worker settings file to devstack_with_worker
-moves course_block api functionality into openedx/core/djangoapps/content/block_structure
26 lines
948 B
Python
26 lines
948 B
Python
"""
|
|
This config file follows the devstack enviroment, but adds the
|
|
requirement of a celery worker running in the background to process
|
|
celery tasks.
|
|
|
|
When testing locally, run lms/cms with this settings file as well, to test queueing
|
|
of tasks onto the appropriate workers.
|
|
|
|
In two separate processes on devstack:
|
|
paver devstack studio --settings=devstack_with_worker
|
|
./manage.py cms celery worker --settings=devstack_with_worker
|
|
"""
|
|
|
|
# We intentionally define lots of variables that aren't used, and
|
|
# want to import all variables from base settings files
|
|
# pylint: disable=wildcard-import, unused-wildcard-import
|
|
from cms.envs.devstack import *
|
|
|
|
# Require a separate celery worker
|
|
CELERY_ALWAYS_EAGER = False
|
|
|
|
# Disable transaction management because we are using a worker. Views
|
|
# that request a task and wait for the result will deadlock otherwise.
|
|
for database_name in DATABASES:
|
|
DATABASES[database_name]['ATOMIC_REQUESTS'] = False
|