[feature] Scheduled Mass Upgrades#460
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR adds the schema and model-layer guardrails needed to support scheduled mass upgrades in openwisp-firmware-upgrader, extending BatchUpgradeOperation with scheduling metadata and a new pre-launch lifecycle state.
Changes:
- Adds
scheduled_at(nullable) and a persistedfirmwarelessflag toBatchUpgradeOperation. - Introduces a new
scheduledbatch status and a(status, scheduled_at)composite index for efficient due-batch scanning. - Extends model validation to enforce immutability rules across
idle→scheduled→in-progresstransitions, with accompanying tests and migrations.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
openwisp_firmware_upgrader/base/models.py |
Adds new scheduling fields/status/index and validation guards for editability/immutability. |
openwisp_firmware_upgrader/migrations/0020_batchupgradeoperation_firmwareless_and_more.py |
Applies the new fields/status/index to the main app via migration. |
tests/openwisp2/sample_firmware_upgrader/migrations/0007_batchupgradeoperation_firmwareless_and_more.py |
Mirrors the same schema changes for the sample app migrations. |
openwisp_firmware_upgrader/tests/test_models.py |
Adds tests covering defaults, status choice, composite index, and editability rules. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if self.build_id != build_id: | ||
| raise ValidationError( | ||
| { | ||
| "build": _( | ||
| "The build cannot be changed while a mass upgrade " | ||
| "is scheduled" | ||
| ) | ||
| } |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
d86b9c2 to
bc62848
Compare
Add the scheduled_at and firmwareless fields, the scheduled status, a composite (status, scheduled_at) index, and the clean() guards that keep a scheduled batch editable until it launches. Related to #380
909f056 to
50cf023
Compare
Scan for due scheduled batches, re-validate the device population at launch time, and dispatch each eligible batch once. Related to #380
Reject a new batch when an active batch or per-device operation already covers the same device population. Related to #380
Add the scheduled_at field to the confirmation form with browser-to-UTC conversion, and show the schedule on the batch list and detail views. Related to #380
Accept scheduled_at on the batch-upgrade endpoint, add reschedule and cancel endpoints backed by a batch-level cancel(), and allow filtering and ordering by scheduled_at. Related to #380
50cf023 to
fa25626
Compare
Send bell notifications when a scheduled upgrade starts, fails re-validation, or any mass upgrade reaches a terminal state. Related to #380
Add the Scheduled Mass Upgrades page and document the new settings, REST endpoints, and changelog entry. Related to #380
Cover scheduled execution, the scheduled-plus-persistent recovery flow, and the confirmation-page schedule widget. Related to #380
fa25626 to
fa00bc9
Compare
Checklist
Reference to Existing Issue
Related to #380 (Scheduled Mass Upgrades, Phase 2).
This builds on the persistent-upgrades work, so for now it's based on
issues/417-persistence-schema-fieldsand the diff only shows the scheduling changes. I'll retarget it togsoc26-persistent-scheduled-upgradesonce persistence merges.Description of Changes
This adds the ability to schedule a mass upgrade for a later maintenance window instead of running it immediately, and to edit or cancel it while it waits.
The batch model gets a
scheduled_attime, a storedfirmwarelessflag and a newscheduledstatus, with a(status, scheduled_at)index for the scan. When you pick a future time on the confirmation page,batch_upgrade()saves the batch asscheduledinstead of dispatching it. A Celery Beat task,execute_scheduled_upgrades, then picks up batches whose time has come, re-checks that there are still devices to upgrade, and launches them; if nothing is eligible by then the batch is marked failed without touching a device.To stop two upgrades from fighting over the same devices, creating a batch that overlaps an active one (or a device that is already mid-upgrade) is rejected, with the conflicting operation named in the error.
While a batch is scheduled you can change the time, the group/location filters, and the persistent and firmwareless options, or cancel it. This works both from the admin (Edit Schedule and Cancel buttons on the batch page) and from the REST API (
reschedule/andcancel/endpoints); both go through the same code so they stay in sync. Times are entered in the browser timezone and converted to UTC on submit, the admin shows them back in the server timezone, and the API uses ISO 8601 with an offset.Notifications go out when a scheduled upgrade starts, when it can't start because no devices are eligible, and when any mass upgrade finishes.
Two settings bound the schedule:
OPENWISP_FIRMWARE_UPGRADER_SCHEDULE_MIN_DELAY(10 minutes) andOPENWISP_FIRMWARE_UPGRADER_SCHEDULE_MAX_HORIZON(180 days).Docs are a new
scheduled-mass-upgrades.rstpage plus updates to the REST API, settings and changelog pages. Migrations are additive for both the default and the sample app, so existing rows need no data migration. Screenshots and the demo video are on thedocsbranch, like the persistent-upgrades ones.