Google Summer of Code Ideas (2017)

Google Summer of Code

Statement added on 28th of February 2017

We haven’t been accepted to the GSoC 2017 but you can still apply to a few accepted organizations which are including many of our ideas in their proposals. See:

Netjsongraph.js: canvas and geographic data

netjsongraph.js is a javascript library based on d3 that allows visualization of NetJSON NetworkGraph objects. The library uses SVG for visualization, which can be quite slow when many elements are shown, therefore we would like to try switching to canvas.

We also need an optional mode in which the network is displayed on a map.

Measurable outcomes:

  • Rewrite the visualizer to use canvas

  • Add an optional map mode

  • Modernize javascript code organization: you may want to use some modern JS tool for building the library, you may rewrite the code in ES6, up to you

  • Update documentation and examples in README

Implement NetJSON DeviceMonitoring in ubus (OpenWRT/LEDE)

Implement NetJSON DeviceMonitoring output in ubus (OpenWRT/LEDE).

We need a way to retrieve a NetJSON DeviceMonitoring object directly from the command line interface.

A good way to implement this would be to do it via ubus, like nodewatcher-agent ubus API.

Measurable outcomes:

  • Implement a way to retrieve a NetJSON DeviceMonitoring object via ubus

  • Document the compilation/install process and the usage of the module on the README

Convert netengine output to NetJSON DeviceMonitoring

netengine is an abstraction layer for extracting information from network devices. It was developed prior to NetJSON and it has helped us understanding that we needed a common format like NetJSON.

We want to change the library so it can return NetJSON DeviceMonitoring output.

Measurable outcomes:

  • Change the JSON output to match NetJSON DeviceMonitoring

  • Implement mocking in tests

  • Add compatibility for OpenWRT Chaos Calmer, Designated Driver and LEDE

  • Add compatibility for AirOS 7

  • Update the documentation contained in the repository

Implement NetJSON NetworkGraph output in B.A.T.M.A.N. Advanced

B.A.T.M.A.N. Advanced is a layer2 routing deamon widely deployed in mesh networks.

It ships a tool called batadv-viz that returns different output formats that can be used to visualze the network.

We want to add NetJSON NetworkGraph output to batadv-viz.

Measurable outcomes:

  • Implement NetJSON NetworkGraph output in batadv-viz

  • Follow the development conventions used in batadv-viz

Ansible plugin for netjsonconfig

Ansible is an IT automation tool that has been recently gaining popularity also in the OpenWRT world.

We want to implement an ansible plugin that integrates netjsonconfig and allows using its two most interesting features, that is templates and context, in ansible.

It should be possible to define configuration templates, assign them to specific playbooks and define specific configurations for hosts.

The configuration format format used by netjsonconfig is NetJSON DeviceConfiguration, but a YAML conversion of NetJSON would be good as well. Support for both would be preferred.

Measurable outcomes:

  • Implement an ansible module that integrates netjsonconfig in ansible and allows using NetJSON DeviceConfiguration (or its YAML equivalent) to configure OpenWRT devices

  • Achieve a test coverage higher than 80%

  • Provide documentation using python-sphinx

Raspbian backend for netjsonconfig

Implement a Raspbian backend in netjsonconfig.

NetJSON DeviceConfiguration has been implemented only on OpenWRT: implementing it on other systems will help to speed up the standardization process.

Measurable outcomes:

  • The Raspbian backend must generate a configuration archive compatible with Raspbian Jessie

  • The Raspbian backend schema must cover at least the following features:

    • general (eg: hostname)

    • ntp settings

    • network interface settings

    • wireless setttings

    • dns servers

    • dns search domains

    • static routes

    • files

  • The general test coverage of the library must be kept higher than 95%

  • The backend must be to be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

PfSense backend for netjsonconfig

Implement a PfSense backend in netjsonconfig.

NetJSON DeviceConfiguration has been implemented only on OpenWRT: implementing it on other systems will help to speed up the standardization process.

Measurable outcomes:

  • The PfSense backend must generate a configuration archive compatible with PfSense 2.2.x

  • The PfSense backend must generate a configuration archive compatible with PfSense 2.3.x

  • The PfSense backend schema must cover at least 75% of the features offered by the PfSense web interface, with particular attention to interfaces, wireless settings, vlans, firewall rules and VPNs

  • The general test coverage of the library must be kept higher than 95%

  • The backend must be to be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

AirOS backend for netjsonconfig

Implement an AirOS backend in netjsonconfig.

NetJSON DeviceConfiguration has been implemented only on OpenWRT: implementing it on other systems will help to speed up the standardization process.

Measurable outcomes:

  • The AirOs backend must generate a configuration archive compatible with AirOS 6.x and AirOS 7.x, two separate classes can be created if preferred

  • The AirOs backend schema must cover at least 75% of the configuration features offered by AirOS web interface, with particular attention to interfaces, wireless settings and vlans

  • The general test coverage of the library must be kept higher than 95%

  • Both backends must be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

netjsonconfig backward conversion

As of today, netjsonconfig is only able to generate a native router configuration (eg: OpenWRT) from a NetJSON DeviceConfiguration object and not vice versa.

We want to add the backward conversion process into the library.

This project will require a thoughtful design, probably involving some serialization and deserialization mechanism.

Measurable outcomes:

  • Backward generate() pocess: a configuration archive must be converted to NetJSON DeviceConfiguration through the available backends

  • Backward render() process: a configuration string (eg: uci export in OpenWRT) must be converted to NetJSON

  • The general test coverage of the library must be kept higher than 95%

  • The feature must be documented in the documentation files contained in the netjsonconfig repo