301c173fe0
We run atomic-requests in almost all environments (for the lms and cms anyway) EXCEPT devstack_with_worker. Using a different setting means that even if you think you are testing with a worker like real deploys use, you are not actually testing with the data a worker would actually see. The removed code also claims that if you run with atomic transactions and a worker you will deadlock the system. If so edx.org would be deadlocked at all times and yet is not. The old code was vintage 2015 and its assumptions probably haven't been examined since then.
23 lines
848 B
Python
23 lines
848 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
|
|
DJANGO_SETTINGS_MODULE=cms.envs.devstack_with_worker celery worker --app=cms.celery:APP
|
|
"""
|
|
|
|
# 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
|
|
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = True
|
|
BROKER_URL = 'redis://:password@edx.devstack.redis:6379/'
|