GSoC Project Ideas 2023

Warning

This page is currently a work in progress and not final.

If you want to apply to GSoC 2023 with us please focus on contributing to OpenWISP before spending effort on any idea listed on this page, at least until the GSoC application period opens.

Tip

Do you want to apply with us?

We have a page that describes how to increase your chances of success. Please read it carefully.

Read our Google Summer of Code guidelines.

General suggestions and warnings

• Project ideas describe the goals we want to achieve but may miss details that have to be defined during the project: we expect applicants to do their own research, propose solutions and be ready to deal with uncertainty and solve challenges that will come up during the project

• Code and prototypes are preferred over detailed documents and unreliable estimates: rather than using your time to write a very long application document, we suggest to invest in writing a prototype (which means the code may be thrown out entirely) which will help you understand the challenges of the project you want to work on; your application should refer to the prototype or other Github contributions you made to OpenWISP that show you have the capability to succeed in the project idea you are applying for.

• Applicants who have either shown to have or have shown to be fast learners for the required hard and soft skills by contributing to OpenWISP have a lot more chances of being accepted: in order to get started contributing refer to the OpenWISP Contributing Guidelines

• Get trained in the projects you want to apply for: once applicants have completed some basic training by contributing to OpenWISP we highly suggest to start working on some aspects of the project they are interested in applying: all projects listed this year are improvements of existing modules so these modules already have a list of open issues which can be solved as part of your advanced training. It will also be possible to complete some of the tasks listed in the project idea right now before GSoC starts. We will list some easy tasks in the project idea for this purpose.

Project Ideas

Adding support for automatic management of ZeroTier Tunnels

Important

Languages and technologies used: Mostly OpenWRT, Python, Django, ZeroTier.

Mentors: Gagan Deep (pandafy), Federico Capoano.

Project size: 350 hours.

Difficulty rate: hard.

OpenWISP Controller already supports configuring OpenVPN, WireGuard and VXLAN over WireGuard tunnels. The goal of this project is to add support for another VPN backend: ZeroTier.

Pre-requisites to work on this project

The contributor must demonstrate good understanding of the following OpenWISP modules:

• netjsonconfig

• OpenWISP Controller

• OpenWISP Network Topology

Any merged patches on any of those modules is considered an important plus point.

The contributor must also demonstrate familiarity with ZeroTier, and OpenWRT, moreover, they should be willing to increase their experience with these technologies and show enthusiasm toward learning and implementing IT network automation.

Expected outcomes

• Add support for ZeroTier in netjsonconfig:

  • Add capability for generating ZeroTier configuration in OpenWrt backend.

  • Add a ZeroTier backend that generates network configuration accepted by REST API endpoints of the ZeroTier Controller.

  • Write documentation for generating configuration for OpenWrt and ZeroTier Controller using netjsonconfig.

  • GitHub Issues:

    • netjsonconfig #207: [feature] Add support for ZeroTier tunnels to OpenWRT backend

    • netjsonconfig #208: [feature] Add ZeroTier backend

• Add ZeroTier as a VPN backend in OpenWISP Controller.

  • Add automatic generation of templates for ZeroTier VPN backend similar to OpenVPN and WireGuard VPN backends.

  • Integrate ZeroTier Controller APIs in OpenWISP Controller to allow managing networks directly from OpenWISP.

  • Write a step by step documentation which explains how to set up and use the new ZeroTier VPN backend with a device.

  • GitHub Issues:

    • openwisp-controller #604 : [feature] Add support for ZeroTier VPN backend

    • openwisp-controller #606 : [feature] Authorize member in ZeroTier network when a new device is added

    • openwisp-controller #605 : [feature] Allow managing ZeroTier networks from OpenWISP

• Add a parser in OpenWISP Network Topology that can parse ZeroTier peer information.

  • Write documentation for using this parser to generate topology from data received from multiple devices.

  • GitHub Issues:

    • openwisp-network-topology #135: [feature] Add a parser for ZeroTier

• Achieve at least 99% test coverage for the code added for this feature.

Improve UX and Flexibility of the Firmware Upgrader Module

Important

Languages and technologies used: Python, Django, OpenWrt.

Mentors: Federico Capoano (more mentors TBA).

Project size: 175 hours.

Difficulty rate: easy/medium.

The goal of this project is to improve the Firmware Upgrader module to make its mass upgrade operation feature more versatile and to improve the user experience by showing progress in real time.

Pre-requisites to work on this project

The applicant must demonstrate good understanding of Python, Django, Javascript and OpenWISP Controller.

They must demonstrate also a basic understanding of OpenWISP Firmware Upgrader, OpenWrt and UI development.

Prior experience with OpenWrt is not extremely required but welcome.

Expected outcomes

The applicant must open pull-requests for the following issues which must be merged by the final closing date of the program:

• [feature] REST API is missing endpoints for DeviceFirmware

• [feature:UI] Show upgrade progress in real time in the UI

• [feature] Allow to perform mass upgrade of devices by their group

• [feature] Allow to perform mass upgrade of devices by their location

Each issue contains the details which the applicant needs to know in order to complete the project successfully.

At each step of code changing the test coverage must be maintained stable and the documentation in the README must be kept up to date.

Training Issues

The applicant may warm up in the application phase by working on the following issues:

• [bug] FileNotFoundError when trying to delete an image which links a non existing file

• [change] Improve endpoints to download firmware images

• [feature] Allow management of UpgradeOperation objects in the admin

Improve UX of the Notifications Module

Important

Languages and technologies used: Python, Django, JavaScript, HTML, CSS

Mentors: Gagan Deep (pandafy) (more mentors TBA).

Project size: 175 hours.

Difficulty rate: medium.

The goal of this project is to improve the user experience for managing of the notification module in regards to managing notification preferences and batching of email notifications.

Pre-requisites to work on this project

The applicant must demonstrate good understanding of OpenWISP Notifications, it’s integration in OpenWISP Controller and OpenWISP Monitoring.

The applicant must demonstrate at least basic UI/UX development skills and eagerness to learn more about this subject.

Expected outcomes

The applicant must open pull-requests for the following issues which must be merged by the final closing date of the program:

• [feature] Batch email notifications to prevent email flooding: this issue has priority because when this happens it causes most users to want to disable email notifications.

• [feature] Allow to disable notifications for all organizations or keep everything disabled except notifications for specific organizations.

• [feature] Add REST API to manage notification preferences of other users.

• [feature] Add a dedicated view for managing notification preferences.

• [feature] Add link to manage notification preferences to email notifications.

Each issue contains the details which the applicant needs to know in order to complete the project successfully.

At each step of code changing the test coverage must be maintained stable and the documentation in the README must be kept up to date.

Applicants are expected to gain more understanding of the UI changes requested with the help of wireframes which must be included in the application; experience in wireframing is considered an important factor, alternatively mentors will guide applicants in learning more about the subject. Willingness and eagerness to learn more about this subject, as well as UI/UX development are paramount.

Training Issues

The applicant may warm up in the application phase by working on the following issues:

• [feature] Add dedicated notification type for internal errors

• [change] Allow relative paths

Add more timeseries database clients to OpenWISP Monitoring

Important

Languages and technologies used: Python, Django, InfluxDB, Elasticsearch.

Mentors: Federico Capoano, Gagan Deep (more mentors TBA).

Project size: 175 hours.

Difficulty rate: medium.

The goal of this project is to add more Timseries DB options to OpenWISP while keeping good maintainability.

Pre-requisites to work on this project

The applicant must demonstrate good understanding of OpenWISP Monitoring, and demonstrate basic knowledge of NetJSON format, InfluxDB and Elasticsearch.

Expected outcomes

• Complete the support to Elasticsearch. Support to Elasticsearch was added in 2020 but was not completed.

  • The old pull request has to be updated on the current code base

  • The merge conflicts have to be resolved

  • All the tests must pass, new tests for new charts and metrics added to influxdb must be added (see [feature] Chart mobile (LTE/5G/UMTS/GSM) signal strength #270)

  • The usage shall be documented, we must make sure there’s at least one dedicated CI build for Elasticsearch

  • We must allow to install and use Elasticsearch instead of InfluxDB from ansible-openwisp2 and docker-openwisp

  • The requests to Elasticsearch shall be optimizesd as described in [timeseries] Optimize elasticsearch #168.

• Add support for InfluxDB 2.0 as a new timeseries backend, this way we can support both InfluxDB <= 1.8 and InfluxDB >= 2.0.

  • All the automated tests for InfluxDB 1.8 must be replicated and must pass

  • The usage and setup shall be documented

  • We must make sure there’s at least one dedicated CI build for Elasticsearch

  • We must allow choosing between InfluxDB 1.8 and InfluxDB 2.0 from ansible-openwisp2 and docker-openwisp.