* fix: Correcting logic for xblock_handler token expiration
The previous math had a date math error which resulted in token expiring in 0-2 days
instead of 2-4 days
Co-authored-by: Feanil Patel <feanil@edx.org>
Co-authored-by: Tim McCormack <tmccormack@edx.org>
This includes the following settings:
- BLOCK_STRUCTURES_SETTINGS : setting dictionary which stores the other different block structures related settings
- BLOCK_STRUCTURES_SETTINGS['PRUNING_ACTIVE'] : keeps only a specific number of versions of each block structure, and deletes the rest
- BLOCK_STRUCTURES_SETTINGS['COURSE_PUBLISH_TASK_DELAY'] : specifies the delay, in seconds, after a new edit of a course is published before updating the block structures cache
- BLOCK_STRUCTURES_SETTINGS['TASK_DEFAULT_RETRY_DELAY'] : Specifies the delay, in seconds, between retry attempts for block structure tasks
- BLOCK_STRUCTURES_SETTINGS['TASK_MAX_RETRIES'] : specifies the max number of retries per block structure task
- BLOCK_STRUCTURES_SETTINGS['STORAGE_CLASS'] : specifies the storage which block structures would be saved to when storage backed block structures are enabled
Example: 'storages.backends.s3boto.S3BotoStorage'
- BLOCK_STRUCTURES_SETTINGS['STORAGE_KWARGS'] : specifies additional arguments needed when utilizing storage for storing storage backed block structures
Example: { bucket: 'test-edxapp' }
- BLOCK_STRUCTURES_SETTINGS['DIRECTORY_PREFIX'] : specifies the path to which storage backed block structures are saved
Example: '/courses/'
This also includes the following waffle switches:
- block_structure.storage_backing_for_cache : enables storage backed block structures, used to retrieve the block structures from storage instead of regenerating the structure, when not available in cache
it is important to note that this is important for production because it reduces response times on block structure related apis
- block_structure.raise_error_when_not_found : raises an error if the block structure requested doesnt exist in store or is outdated
- block_structure.invalidate_cache_on_publish : invalidates the block structure cache when courses are published
For an example with additional context, see the following forum post:
https://discuss.openedx.org/t/help-please-very-slow-load-time-10-seconds-for-courseware-on-sections-with-several-subsections-and-xblocks/2998/16
This also includes information about the toggles that will likely be deprecated and removed:
https://github.com/edx/edx-platform/pull/26175#issuecomment-769080286
This tests the various steps of the rotation process work as we expect.
We set the reference time explicitly due to the bug we found in the
hashing logic which will be fixed in a future ticket.
The keys will fallback to the Django SECRET_KEY if it's not set or is an
empty list. Instructions for the rotation process are in a comment near
the usage of the new keys in openedx/core/djangoapps/xblock/utils.py.
The learning_sequences app has its own model for Course Outlines.
Prior to this commit, these course outlines were only populated by
a management command in the learning_sequences app that queried
modulestore. This commit does a few things:
1. Move the update_course_outline command to live in contentstore
(i.e. Studio). This makes learning_sequences unaware of
modulestore, and makes it easier for us to extract it from
edx-platform (or to plug in different kinds of course outlines).
2. Add tests.
3. Add performance and debug logging to course outline creation.
4. Make course outline creation happen every time a course publish
happens.
This will allow us to start collecting data about how long building
course outlines takes, and get error reporting around any content
edge cases that break the course outline code.
These changes were initially made to make it easier to do SECRET_KEY rotations. Along the way, we found it made sense to refractor the code as well.
Changes made:
- changed get_to_create to create because now the code should only get to this block when a write is necessary
- added a lookup for anonymous_user_id. This is to return an existing anonymous_user_id rather than calculating. This will mitigate the results of SECRET_KEY rotation.
- Added monitoring to help us make better decisions: should we not sue SECRET_KEY, performance considerations...
- put old function behind toggle in case something goes wrong in production with new code
- refractoring function structure for better understanding
This addresses a longstanding TODO item to make runtime.anonymous_student_id for content libraries v2 work the same way as it does for XBlocks in regular courses, persisting the "context ID" (equivalent to course ID) to the database. This way, if SECRET KEY is changed, existing anonymous IDs will continue to work unchanged.
This is a potentially breaking change, but should mostly affect capa problems using external code graders or Matlab code input, and I'm not aware of any such usage of the new runtime / libraries v2.
Instead of adding new attributes for each cookie name we create
consistent attribute names. This should prevent any issues where we
have too many different unique attribute names because the cookie names
are unique to the user.
We added two new settings to make the number of cookies and groups
capture configurable:
- TOP_N_COOKIES_CAPTURED
- TOP_N_COOKIE_GROUPS_CAPTURED
