The test count was off because without warnings disabled, it was also
counting warning lines as tests.
The `head -n -2` grabs everything but the last two lines which contain a
count (not sure why this isn't used). If you run without
`--disable-warnings` this will include any warnings that occur during
test collection which we don't want in this case.
The LMS and Studio need to set values for CORS_ALLOW_HEADERS so that the
MFEs can work properly, since preflight requests will need to send over
extra headers. Prior to this commit, CORS_ALLOW_HEADERS was being
redefined in multiple places in edx-platform and again in Tutor's config
because it was only being conditionally set if ENABLE_CORS_HEADERS was
True (which was a policy setting). But CORS_ALLOW_HEADERS is application
logic in that the value is determined by what the view needs, and won't
vary by deployment.
By consolidating this to always be defined in the common.py files, we
make sure that deployment environments don't have to define it. An
example of where this bit us was when course import in the course
authoring MFE did not work because Tutor was using an outdated value for
this setting.
A followup to this would be to just rip out the ENABLE_CORS_HEADERS
setting entirely, and just always have it on. But that would benefit
from a little more discovery to make sure there's no weird use case that
still requires it to be False (maybe something in the test suite?).
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
replaced non encrypted fields of blackboard config model with encrypted ones
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/feanil/fix_one_upgrade`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/feanil/fix_one_upgrade`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/feanil/fix_one_upgrade`
* fix: Multiple auto-tagging when creating a course
* Avoid tagging course-block and course-info blocks
* Tests
* feat: Avoid create index for course blocks
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/feanil/fix_one_upgrade`
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/feanil/fix_one_upgrade`
We were seeing the following error:
```
/usr/bin/git add -- requirements scripts/**/requirements
fatal: pathspec 'scripts/**/requirements' did not match any files
```
Once we introduce wildcards, the whole path needs to be valid so adding
a trailing wildcard to catch all the relevant directories and files.
Routine requirement upgrade. Doing it individually because there are too many changes in `make upgrade`.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/feanil/fix_one_upgrade`
Prior to this commit, the LMS would log the following error in tutor
production:
pymongo/topology.py:175: UserWarning: MongoClient opened before fork.
Create MongoClient only after forking. See PyMongo's documentation for
details:
https://pymongo.readthedocs.io/en/stable/faq.html#is-pymongo-fork-safe
Quoting from that page:
> PyMongo is not fork-safe. Care must be taken when using instances of
> MongoClient with fork(). Specifically, instances of MongoClient must
> not be copied from a parent process to a child process. Instead, the
> parent process and each child process must create their own instances
> of MongoClient. Instances of MongoClient copied from the parent
> process have a high probability of deadlock in the child process due
> to the inherent incompatibilities between fork(), threads, and locks
> described below. PyMongo will attempt to issue a warning if there is a
> chance of this deadlock occurring.
For edx-platform, the MongoClient connection is initalized with the
modulestore() invocation. That call creates and caches a global variable
that Studio or the LMS will reuse across the life of the worker process.
That initialization was put into lms/wsgi.py in 7c758ec9, but originated
in lms/startup.py with 51d0dd1. The original reason for it is because at
that time (2013), we still supported the XML Modulestore, which stored
courses on disk as directories of OLX files and static assets. The XML
Modulestore would then read the entirety of those courses into memory at
startup. This meant that the startup process was *extremely* expensive,
so we needed to have it happen before the workers started serving
requests to users, instead of having the system lazily read them in when
the first user request arrived.
Loading course content in this form hasn't been supported since 2016,
meaning that modulestore initialization is no longer the performance
time bomb that it once was. The fact that this code remained here is
likely an oversight, which was considered harmless until @ztraboo
reported these pymongo log messages during the course of investigating
performance issues:
https://discuss.openedx.org/t/atlas-mongodb-performance-issues-un-indexed-queries/12803/16
Two potential followups that should be explored after this:
1. Tutor should probably be forking earlier than this, before we load
Django settings and initialize database and cache connections.
2. It's possible that the caching mechanism for modulestore should be
revisited to operate at the request cache level. The performance
benefit of keeping it around may not be worth the potential memory
leaks. Anything we do here would have to be very carefully monitored
though, since connection costs may add up.
There was a logical error in the compile_sass management command:
instead of falling back to settings.COMPREHENSIVE_THEME_DIRS when
--theme-dirs was *None or missing*, we only fell back to it when
--theme-dirs was *missing*.
This caused theme compilation to be skipped when COMREHENSIVE_THEME_DIRS
*is not set* in the environment, even though
settings.COMPREHENSIVE_THEME_DIRS *is set* in Django settings, which
is currently the case for edx.org.
