Allow to use maintenance while the migrations are in progress #2676
Conversation
📝 WalkthroughWalkthroughThe pull request introduces configuration changes focusing on maintenance mode management and environment-specific settings. The modifications enhance the application's flexibility by implementing a more structured backend approach for maintenance states, adding new environment variables, and introducing conditional maintenance mode handling in deployment scripts. These changes aim to provide more granular control over system configurations and operational states. Changes
Sequence DiagramsequenceDiagram
participant Script as Celery Beat Script
participant App as Django Application
participant DB as Database
alt AUTO_MAINTENANCE_MODE is true
Script->>App: Enable Maintenance Mode
Script->>DB: Run Migrations
Script->>App: Disable Maintenance Mode
else AUTO_MAINTENANCE_MODE is false
Script->>DB: Run Migrations
end
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
scripts/celery_beat.sh (1)
9-11: Consider adding error handling for maintenance mode operations.While the maintenance mode toggle is well-placed, it might be good to add some error handling. You know, just in case something goes wrong during migrations (it never does, right? 😏).
if [[ "${AUTO_MAINTENANCE_MODE}" == "true" ]]; then - python manage.py maintenance_mode on + if ! python manage.py maintenance_mode on; then + echo "Failed to enable maintenance mode" + exit 1 + fi fi python manage.py migrate --noinput python manage.py compilemessages -v 0 python manage.py load_redis_index if [[ "${AUTO_MAINTENANCE_MODE}" == "true" ]]; then - python manage.py maintenance_mode off + if ! python manage.py maintenance_mode off; then + echo "Failed to disable maintenance mode" + # Consider if you want to exit here or continue + exit 1 + fi fiAlso applies to: 17-19
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
config/settings/base.py(1 hunks)config/views.py(2 hunks)scripts/celery_beat.sh(1 hunks)
🔇 Additional comments (2)
config/views.py (1)
4-6: LGTM! Smart choice keeping the health check endpoint accessible.
The addition of force_maintenance_mode_off decorator ensures that monitoring systems can still verify the application's heartbeat during maintenance windows.
Also applies to: 17-17
config/settings/base.py (1)
427-427: Good choice using CacheBackend for maintenance mode state.
Using the cache backend is more reliable for distributed environments and aligns well with the existing Redis configuration.
Let's verify the cache configuration is properly set up:
✅ Verification successful
Well, someone certainly did their homework with the cache configuration
The Redis cache backend is indeed properly configured, making the CacheBackend choice for maintenance mode quite appropriate. The setup includes:
- A properly configured Redis cache as the default backend
- Redis URL configuration with a sensible default
- Test environment gracefully falling back to a dummy cache
I suppose we can all sleep better knowing the maintenance mode state will be reliably stored in Redis, synchronized across all instances. How... comforting.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Redis cache configuration exists and is properly configured
# Check if Redis cache backend is configured
rg -A 5 "CACHES.*=.*{" config/settings/
Length of output: 129
Script:
#!/bin/bash
# Let's try a more precise search for cache configuration
rg -l "CACHES\s*=" config/settings/
# Also search for Redis-related configuration
rg -l "REDIS" config/settings/
# And check the actual content of base.py where we saw the maintenance mode config
cat config/settings/base.py | grep -A 10 -B 10 "MAINTENANCE_MODE"
Length of output: 1283
Script:
#!/bin/bash
# Let's see the actual cache configuration in both files
cat config/settings/base.py | grep -A 10 "CACHES\s*="
cat config/settings/test.py | grep -A 10 "CACHES\s*="
# And check if there's any Redis URL configuration
rg "REDIS_URL" config/settings/
Length of output: 1054
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #2676 +/- ##
========================================
Coverage 70.48% 70.48%
========================================
Files 201 201
Lines 11439 11439
Branches 1164 1164
========================================
Hits 8063 8063
Misses 3014 3014
Partials 362 362 ☔ View full report in Codecov by Sentry. |
Proposed Changes
Merge Checklist
/docsOnly PR's with test cases included and passing lint and test pipelines will be reviewed
@ohcnetwork/care-backend-maintainers @ohcnetwork/care-backend-admins
Summary by CodeRabbit
New Features
Bug Fixes