diff --git a/developer/gsoc-ideas-2026.rst b/developer/gsoc-ideas-2026.rst index 25c9f7b8..40487b03 100644 --- a/developer/gsoc-ideas-2026.rst +++ b/developer/gsoc-ideas-2026.rst @@ -65,19 +65,11 @@ Automatic Extraction of OpenWrt Firmware Image Metadata **Difficulty rate**: medium/hard. -This GSoC project aims to improve the user experience and reliability of -`OpenWISP Firmware Upgrader +This GSoC project aims to improve the user experience of `OpenWISP +Firmware Upgrader `__ by -automatically extracting authoritative metadata from OpenWrt firmware -images at upload time. - -Currently, users must manually provide metadata such as image identifiers, -target architectures, and board compatibility. This process is error-prone -and does not scale well as the number of supported images grows. - -The proposed solution will introduce an automated workflow that analyzes -uploaded images, extracts relevant metadata, and pre-fills or validates -image fields to simplify upgrades and prevent misconfiguration. +automatically extracting metadata from OpenWrt firmware images at upload +time. When uploading firmware images to OpenWISP Firmware Upgrader, users are currently required to manually provide metadata such as the image @@ -93,10 +85,9 @@ device tree structures. Expected outcomes +++++++++++++++++ -Introduce a future enhancement to OpenWISP Firmware Upgrader that -**automatically extracts authoritative metadata** from OpenWrt firmware -images at upload time and uses it to automatically fill and validate image -fields. +Introduce logic in OpenWISP Firmware Upgrader to automatically **extract +metadata from OpenWrt firmware images** upon upload, using it to pre-fill +and validate image fields. 1. **Initial upload** @@ -162,6 +153,16 @@ fields. with devices. After that, it becomes read-only - otherwise things break and it's too painful to handle all the edge cases. +4. **Other constraints** + + - Test coverage **must not decrease**, tests must follow the specs + described in the *"Testing strategy"* section below. + - Documentation needs to be updated to account for this feature, + including updating any existing screenshots that may change the look + of the UI after implementation. + - Once the project is completed, we will need a short example usage + video for YouTube that we can showcase on the website/documentation. + Build-level status ++++++++++++++++++ @@ -206,8 +207,8 @@ can need 10-100MB+). We should: - Make memory limits configurable with reasonable defaults for typical OpenWrt images. - Detect when an image would exceed memory thresholds. -- Handle OOM gracefully via ``generic_notification`` (since we can't - validate during Django model save - compression ratios vary). +- Handle out of memory gracefully via ``generic_notification`` (since we + can't validate during Django model save - compression ratios vary). - Consider limiting decompression output size to prevent zip bomb-style attacks. @@ -221,6 +222,19 @@ a transient issue. **Task crashes:** Treat as failure, notify user, fallback to manual intervention. +**Extensibility**: the mechanism for extracting metadata varies across +operating systems. + +Although OpenWISP currently focuses exclusively on OpenWrt, it also +manages devices running OpenWrt derivatives which can have varying degrees +of difference with the standard OpenWrt source code. + +To handle these differences, this module uses the concept of an **Upgrader +Class**. Therefore, the logic described here should be implemented in a +similar object-oriented structure, allowing for customization, extension, +or complete override if needed. Each upgrader class must have a related +meta-data extraction class. + Benefits ++++++++ @@ -338,7 +352,7 @@ which provides splash page functionality for WiFi hotspot networks. The focus is on codebase improvements, architectural refactoring, dependency upgrades, and new features to enhance maintainability and user experience. -All refactoring work should maintain backward compatibility—since users +All refactoring work should maintain backward compatibility, since users interact with the application through their browsers, these internal code changes should be transparent to them. @@ -413,7 +427,7 @@ and reduce technical debt: react-redux, etc.) - Migrating away from Enzyme (deprecated) to React Testing Library (RTL). Contributors should propose a migration strategy that balances - thoroughness with contributor workload—whether to migrate all tests + thoroughness with contributor workload, whether to migrate all tests at once or incrementally alongside the React upgrade. - Ensuring all dependencies are compatible with React 19 - Comprehensive testing to catch regressions @@ -443,7 +457,7 @@ Testing Strategy Testing should follow these guidelines: -- TDD (Test-Driven Development) is recommended but not mandatory—use +- TDD (Test-Driven Development) is recommended but not mandatory, use judgment based on the specific task. - Test coverage levels for refactored components should not decrease from current levels. diff --git a/general/roadmap-2030.rst b/general/roadmap-2030.rst index 40e148ff..87fe87fb 100644 --- a/general/roadmap-2030.rst +++ b/general/roadmap-2030.rst @@ -262,21 +262,34 @@ Wireless Support Firmware Upgrade UX ------------------- -.. note:: - - Part of these subjects have been worked on during Google Summer of - Code 2025; see the project board `[GSoC25] Firmware Upgrader UX - improvements `_. - - **Group Upgrades**: Extend firmware upgrade capabilities to allow targeting specific device groups, in addition to per-device or per-organization options. + + *Status update*: `Work in progress (openwisp-firmware-upgrader/pull/377) + `_ + - **Real-Time Progress Tracking**: Enhance visual feedback to provide live status updates during firmware upgrades without requiring page refreshes. -- **Persistent Upgrade Tasks**: Implement support for continuous upgrades + + *Status update*: `Work in progress (openwisp-firmware-upgrader/pull/377) + `_ + +- **Persistent Mass Upgrades**: Implement support for continuous upgrades that remain queued for offline devices, executing automatically once they reconnect. + + *Detailed plan*: `Github: Persistent Mass Upgrades + `__. + +- **Scheduled Mass Upgrades**: Introduce support for scheduled mass + upgrades, allowing a mass upgrade operation to start at a user defined + datetime in the future. + + *Detailed plan*: `Github: Scheduled Mass Upgrades + `__. + - **Automated Firmware Image Identification** - **Removal of Predefined Image Types**: Eliminates the need for @@ -297,6 +310,9 @@ Firmware Upgrade UX - **Reduced Maintenance Overhead**: Avoids the need for administrators to track internal OpenWrt or vendor-specific image identifiers, which frequently change over time. + - *Detailed plan*: `Github: Automatic extraction of image metadata from + OpenWrt firmware images + `__. Monitoring Improvements -----------------------