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.
This fixes a misuse of New Relic terminology. Here we are in fact using
custom attributes; custom metrics are a different thing that we may start
using in the future.
This uses the new names introduced in edx-django-utils
3.8.0 (edx/edx-django-utils#59), which we're already using, as
well as updating a few other locations where we incorrectly refer
to New Relic custom metrics instead of custom attributes.
Includes a couple of unrelated lint fixes in a file I modified.
Since code-annotations==0.7.0, incremental_release, launch_date,
monitored_rollout, graceful_degradation, beta_testing are all considered
as "temporary" use cases.
