Is your feature request related to a problem? Please describe.
openwisp-firmware-upgrader is gaining a "persistent mass upgrades" feature (parent issue openwisp/openwisp-firmware-upgrader#379, implementation in PR #436). The feature introduces two new Celery Beat tasks:
openwisp_firmware_upgrader.tasks.check_pending_upgrades — scans for offline-device upgrades whose next_retry_at has elapsed and dispatches retry workers (recommended cadence: 10 minutes).openwisp_firmware_upgrader.tasks.send_pending_upgrade_reminders — scans for long-running persistent batches and fires a generic_message notification when each batch's reminder cadence has elapsed (recommended scan cadence: 7 days; per-batch reminders every 60 days, configurable via OPENWISP_FIRMWARE_UPGRADER_PERSISTENT_REMINDER_PERIOD).
The package only registers these tasks in its own test settings. On an ansible-openwisp2 install the CELERY_BEAT_SCHEDULE = { … } block in templates/openwisp2/settings.py (lines 249-330) is the source of truth, with per-module Jinja gates for users/notifications/monitoring/radius/metrics. There is no firmware-upgrader block in that schedule, and no openwisp2_firmware_upgrader_periodic_tasks toggle in defaults/main.yml matching the pattern used for monitoring/radius/metrics at lines 234-236. Without these, neither the retry loop nor the reminder notifications fire on ansible-deployed installs once the next firmware-upgrader release lands.
Describe the solution I would implement
I would like to add the firmware-upgrader Beat entries and the matching ansible variables, following the same shape as the existing openwisp2_monitoring_periodic_tasks wiring.
-
In templates/openwisp2/settings.py, inside the CELERY_BEAT_SCHEDULE = { … } block at lines 249-330, add the two new entries. Placement-wise they fit next to the run_checks entry (which is also a periodic scan, gated the same way):
{% if openwisp2_firmware_upgrader and openwisp2_firmware_upgrader_periodic_tasks %}
"check_pending_upgrades": {
"task": "openwisp_firmware_upgrader.tasks.check_pending_upgrades",
"schedule": timedelta(minutes={{ openwisp2_firmware_upgrader_check_pending_period_minutes }}),
},
"send_pending_upgrade_reminders": {
"task": "openwisp_firmware_upgrader.tasks.send_pending_upgrade_reminders",
"schedule": timedelta(days={{ openwisp2_firmware_upgrader_reminder_scan_period_days }}),
},
{% endif %}
-
In defaults/main.yml:
- Add the toggle next to the existing
*_periodic_tasks flags at lines 234-236, and the period knobs next to the existing openwisp2_celery_firmware_upgrader* worker tunables around lines 95-99:
openwisp2_firmware_upgrader_periodic_tasks: true
openwisp2_firmware_upgrader_check_pending_period_minutes: 10
openwisp2_firmware_upgrader_reminder_scan_period_days: 7
- Defaults of 10 minutes and 7 days are the recommended cadences from the upstream feature design. Operators tuning for very large fleets or aggressive cadences can override these from inventory without re-running the rest of the playbook.
-
In README.md, document the three new variables in the variables-reference table alongside the existing openwisp2_monitoring_periodic_tasks row — one line each, same column layout.
-
The cron_* style strings in vars/main.yml (lines 8-19, e.g. cron_cleanup_stale_radacct: "'hour': 0, 'minute': 20") are used by the radius/users entries that schedule via crontab(**{ {{ cron_* }} }). Persistent retry and reminder scans don't really benefit from a fixed-clock schedule — they're "scan every N minutes/days" workloads, not "run at 3:30am" workloads — so timedelta(...) is the right primitive and no cron_* entries are needed. Flagging this in case the project prefers the crontab form for consistency.
Tracked under the persistent-mass-upgrades parent in openwisp-firmware-upgrader so the docs PR there can link back here for deployers.
Is your feature request related to a problem? Please describe.
openwisp-firmware-upgrader is gaining a "persistent mass upgrades" feature (parent issue openwisp/openwisp-firmware-upgrader#379, implementation in PR #436). The feature introduces two new Celery Beat tasks:
openwisp_firmware_upgrader.tasks.check_pending_upgrades— scans for offline-device upgrades whosenext_retry_athas elapsed and dispatches retry workers (recommended cadence: 10 minutes).openwisp_firmware_upgrader.tasks.send_pending_upgrade_reminders— scans for long-running persistent batches and fires ageneric_messagenotification when each batch's reminder cadence has elapsed (recommended scan cadence: 7 days; per-batch reminders every 60 days, configurable viaOPENWISP_FIRMWARE_UPGRADER_PERSISTENT_REMINDER_PERIOD).The package only registers these tasks in its own test settings. On an ansible-openwisp2 install the
CELERY_BEAT_SCHEDULE = { … }block intemplates/openwisp2/settings.py(lines 249-330) is the source of truth, with per-module Jinja gates for users/notifications/monitoring/radius/metrics. There is no firmware-upgrader block in that schedule, and noopenwisp2_firmware_upgrader_periodic_taskstoggle indefaults/main.ymlmatching the pattern used for monitoring/radius/metrics at lines 234-236. Without these, neither the retry loop nor the reminder notifications fire on ansible-deployed installs once the next firmware-upgrader release lands.Describe the solution I would implement
I would like to add the firmware-upgrader Beat entries and the matching ansible variables, following the same shape as the existing
openwisp2_monitoring_periodic_taskswiring.In
templates/openwisp2/settings.py, inside theCELERY_BEAT_SCHEDULE = { … }block at lines 249-330, add the two new entries. Placement-wise they fit next to therun_checksentry (which is also a periodic scan, gated the same way):In
defaults/main.yml:*_periodic_tasksflags at lines 234-236, and the period knobs next to the existingopenwisp2_celery_firmware_upgrader*worker tunables around lines 95-99:In
README.md, document the three new variables in the variables-reference table alongside the existingopenwisp2_monitoring_periodic_tasksrow — one line each, same column layout.The
cron_*style strings invars/main.yml(lines 8-19, e.g.cron_cleanup_stale_radacct: "'hour': 0, 'minute': 20") are used by the radius/users entries that schedule viacrontab(**{ {{ cron_* }} }). Persistent retry and reminder scans don't really benefit from a fixed-clock schedule — they're "scan every N minutes/days" workloads, not "run at 3:30am" workloads — sotimedelta(...)is the right primitive and nocron_*entries are needed. Flagging this in case the project prefers the crontab form for consistency.Tracked under the persistent-mass-upgrades parent in openwisp-firmware-upgrader so the docs PR there can link back here for deployers.