We would like new devstack instances to better support the user retirement pipeline out of the box after provisioning. The first step is to update the default list of retirement states devstack is configured to add/use.
This change disables the profiling panel for performance reasons. It's
rarely useful anyway, given the lack of granularity in the data it
displays.
This commit also enables the Cache panel, which is import for tracking
where we're making excessive calls to redis/memcached.
Blockstore and all of its (experimental) functionality has been replaced with
openedx-learning, aka "Learning Core". This commit uninstalls the now-unused
openedx-blockstore package and removes all dangling references to it.
Note: This also removes the `copy_library_from_v1_to_v2` management command,
which has been broken ever since we switched from Blockstore to Learning Core.
Part of this DEPR: https://github.com/openedx/public-engineering/issues/238
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?).
This commit corrects the EXAMS_DATE_MICROFRONTEND_URL devstack setting to EXAMS_DASHBOARD_MICROFRONTEND_URL. This ensures that the exams dashboard can load in the Instructor Dashboard when an LTI-based proctoring provider is selected.
* Update location in devstack-experimental to fix issue while re-indexing
* Updated the devstack.py to point to edx.devstack.elasticsearch710 host
* Enabed the ENABLE_COURSEWARE_INDEX and ENABLE_COURSEWARE_SEARCH
We get about one email per month from people looking for access to edX
APIs. Those emails come to the now almost-defunct oscm@edx.org email
address. I think that's because of these swagger references.
I suppose someone could find this email address on an Open edX
installation, and people would write to it, but I find in practice this
doesn't happen.
Co-authored-by: Kyle McCormick <kyle@tcril.org>
* feat: Add a script to enhance JWKs in preparation for move from pyjwkest
This script accepts a signing JWK (presumably `JWT_PRIVATE_SIGNING_JWK`)
and ensures that it has all of the precomputed private numbers that are
required for top performance. This is necessary before moving away from
pyjwkest to PyJWT for signing JWTs. See issue
<https://github.com/openedx/edx-drf-extensions/issues/290>. (Alternatively,
one could remove the p, q, dp, dq, and qi params, but there is an unknown
performance cost to doing so as we are not currently caching these keys,
and the precompution happens on every load due to the way pyjwkest's API
works.)
* fixup! Upgrade devstack at the same time
Gate access to exam content by requiring an access token. This is a signed JWT issued by the edx-exams service that grants a user access to a sequence locator for a short lived window while an exam is in progress. This feature only applies to courses using the new exam service instead of edx-proctoring.
[APER-2240]
The monolith no longer needs to understand how to build URLs to the Learner Record MFE. The Credentials IDA has logic to determine if (and how) a request should be redirected to this MFE. This PR remove unused settings from edx-platform.
We have already removed the use of these settings in #31672.
Clearing the RequestCache was intended to address memory leaks in the
celery workers. Celery worker processes will process many tasks before
they are terminated. RequestCache cleanup typically happens in the
RequestCacheMiddleware class, and middleware never executes for celery.
To get around that issue, the CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION
setting was created to clear the RequestCache after every task was
successfully completed.
This works fine when celery is running as a separate process, as it's
set up to do in production. But during development, the
CELERY_ALWAYS_EAGER setting variable is set to True, meaning that
celery tasks are run in the same thread as the Django Request. This is
meant to make debugging easier, as task failures run as part of the
request cycle and will raise exceptions that are visible to the
browser.
However, celery tasks are triggered from many different actions. That
means that the RequestCache was being cleared many times during the
course of processing a request. This led to behavior that was
potentially slower, but also incorrect–the RequestCache was getting
flushed in a way that wouldn't happen in any deployed environment
because celery would be running in separate processes there. This came
up when trying to fix an issue around extra history records being
created during problem submissions:
https://discuss.openedx.org/t/extra-history-record-stored-on-each-problem-submission/8081
Furthermore, it's not necessary to prevent RequestCache memory leaks
when running in CELERY_AWLAYS_EAGER mode in development because the
middleware cleanup happens automatically–as everything is running as
part of the request/response cycle.
There are times in which we may want to run celery eagerly and still
clear the cache, such as testing. I have set
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = False in all dev and test
environments that already have CELERY_ALWAYS_EAGER = True. The unit
test that specifically tests whether the request cache is getting
cleared upon completion of a celery task then overrides
CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = True even though
CELERY_ALWAYS_EAGER = True for the sake of that specific testing
purpose.
Call into the exam service instead of the edx-proctoring plugin on course publish if the course_apps.exams_ida course waffle flag is enabled. This is an early step in moving away from edx-proctoring
[APER-1922]
We are converting the legacy UI of the `records` app in the Credentials IDA (credentials.edx.org/records/, credentials.edx.org/records/programs/{uuid}, etc.) to a new MFE. Today, the Program Dashboard and the legacy (non-MFE) profile page have buttons that route learners to the Credentials IDA pages. We need to (optionally) introduce a way to route learner's to the new MFE instead.
- Introduces a new configuration setting called `LEARNER_RECORD_MICROFRONTEND_URL` (defaulting to None). This will be used by the LMS to store the base URL of the new MFE (e.g. records.stage.edx.org).
- Introduces a new waffle switch named `USE_LEARNER_RECORD_MFE`. This will be used to control whether routing learner's to the new MFE is enabled from the LMS's side.
- Updates the existing `get_credentials_records_url` function to add additional logic that will determine if we need to build a link to the legacy FE or the new MFE
- Adds tests for new and existing behavior. There were no existing unit tests for the utility function that I updated.
* fix: update learner home api
* refactor: update learner home API pathing
* fix: remove unused logger
* fix: remove unused import
* style: make pylint happy
* style: remove extra space
* style: remove extra space
Co-authored-by: nsprenkle <nsprenkle@2u.com>
Co-authored-by: Nathan Sprenkle <nsprenkle@users.noreply.github.com>
