Passing in the INSTALLED_APPS lambda seems to result in some tasks for certain apps
like instructor_task and bulk_email to not get discovered properly.
OeX_ES-44: Update edx-search elasticsearch.
* removes redundant doc_types from the lms/cms, replaces courseware
index with doc_types to two indices
* code polishing
* Use a new config variable for ES7 deployment. (#2226)
Co-authored-by: Golub-Sergey <1.golub.sergey.1@gmail.com>
Co-authored-by: Diana Huang <diana.k.huang@gmail.com>
If the library content block is already in the course, then don't
refresh the children when we re-import it. This lets us address
TNL-7507 (Randomized Content Block Settings Lost in Course Import)
while still avoiding AA-310, where the IDs of the children for an
existing library_content block might be altered, losing student
user state.
When importing, we only copy the default values from content
in a library the first time that library_content block is created.
Future imports ignore what's in the library so as not to disrupt
course state. You can still update to the library via the Studio
UI for updating to the latest version of a library for this block.
This change was originally made in preparation for a BD-14
change that would enable database-backed organizations
across Open edX. Since then, we've figured out a way
of rolling out database-backed organizations without
mandating that organization slugs in new courses are
validated. So, this puts devstack back to where it was before,
with ORGANIZATIONS_APP==True for LMS on devstack and
ORGANIZATIONS_APP==False for Studio on devstack.
From a developer perspective, this means that course
runs can again be created in Studio with any org slug.
TNL-7425
Search indexing is prohibitively slow for large CCX courses, even
taking hours in the case of some particularly large ones with
thousands of blocks. Temporarily disabling this functionality until
it can be made more performant (PSRE-288), so that we're not
blocking the workers from doing more latency-sensitive work.
There is a separate effort to put search indexing in its own set
of workers.
We introduce the documentation of django settings via code annotations.
This will allow us to produce a human-readable documentatio of all Open
edX settings.
Currently, LMS uses 3 Celery workers: lms_default_1, lms_high_1 and
lms_high_mem_1. Each Celery worker sends messages to a single queue:
edx.core.default, edx.core.high and edx.core.high_mem, respectively.
The number of child processes per Celery worker is set to 1. Due to
this configuration, any task in a queue blocks all other tasks.
Currently, the Celery check task submitted by the /heartbeat?extended
LMS HTTP API endpoint runs in the default queue. When some slow task
(eg course grades creation) is sent to the default queue, it will
block the Celery check task, which will expire and the heartbeat endpoint
will fail. This patch moves the task to another queue which has
only shorter tasks and in which this problem will not occur.
Use a Django setting for the Celery check task routing key so that
it can be overriden by individual OpenEDX instances via JSON
env files.
