From d4c00f2a2185192222a203f1c39a691593f54868 Mon Sep 17 00:00:00 2001 From: Federico Capoano Date: Mon, 9 Feb 2026 19:50:51 -0300 Subject: [PATCH 1/3] [docs] GSoC26: proof read fw upgrade meta-data extraction --- developer/gsoc-ideas-2026.rst | 52 ++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 19 deletions(-) diff --git a/developer/gsoc-ideas-2026.rst b/developer/gsoc-ideas-2026.rst index 25c9f7b8..8255fb43 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. From 20380264066c1ed22abecb83d3f1795cc7df41d9 Mon Sep 17 00:00:00 2001 From: Federico Capoano Date: Mon, 9 Feb 2026 19:51:03 -0300 Subject: [PATCH 2/3] [docs] GSoC26: minor formatting improvements to WLP idea --- developer/gsoc-ideas-2026.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/developer/gsoc-ideas-2026.rst b/developer/gsoc-ideas-2026.rst index 8255fb43..40487b03 100644 --- a/developer/gsoc-ideas-2026.rst +++ b/developer/gsoc-ideas-2026.rst @@ -427,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 @@ -457,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. From 5a40a1232c02b3ec6f23979f2ab06f194394de60 Mon Sep 17 00:00:00 2001 From: Federico Capoano Date: Mon, 9 Feb 2026 20:14:53 -0300 Subject: [PATCH 3/3] [docs] Roadmap status update for FW upgrader UX section --- general/roadmap-2030.rst | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) 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 -----------------------