IoT/Project Deployment Requirements

Background

Eclipse IoT is getting to a point where we have a dozen projects that are starting to produce releases. However, in order to facilitate the use of these releases by a maximum number of people, there are some issues to address.

This document aims at listing these issues, and identifying the actions to take to address them. The long-term goal is to make sure that our IoT projects can be easily, and in a consistent way, consumed by developers or end-users who use typical IoT hardware platforms (often ARM-based – e.g Raspberry Pi, BeagleBone, ...), or cloud environments.

Eclipse IoT landscape

The Eclipse IoT projects spread from lightweight protocol libraries like the ones delivered by Paho or Californium, to more complete frameworks like Kura or SmartHome. They also are implemented in a variety of programming languages.

Several programming languages

While e.g. native C code is not really new at Eclipse (think SWT), there is an even wider variety of programming languages used by the Eclipse IoT projects:

• C/C++: Paho, Mihini, EclipseSCADA, Wakaama, Mosquitto/RSMB, Kura
• Objective-C: Paho
• Python: Paho
• Lua: Mihini, Paho
• Javascript: Ponte, Paho
• Go: Paho
• Java: Paho, EclipseSCADA, Concierge, Eclipse SmartHome, Kura, OM2M, Californium

Because of this variety of programming languages, we need to improve the build and deployment infrastructure at Eclipse to allows proper compilation, testing, signing and packaging for these projects.

Server vs. Embedded

While technologies like Mosquitto or Ponte can certainly run on embedded platforms, it's more likely that they are to be deployed on servers. Server-side technologies need to be easy to install in cloud environments, meaning that they should be available as packages (Linux, NPM, ...) on the most common package managers. Embedded technologies need to be easy to install on constrained platforms, meaning that we e.g. want to provide pre-built binaries.

Vision

Nowadays, setting up a Linux machine with a LAMP stack is trivial, and can probably be done in less than 10 minutes by most people. We want the installation and deployment of Eclipse IoT technology to be that simple.

Target environments

Eclipse IoT projects target embedded devices as well as servers, and we want to make sure we provide a way for any Eclipse IoT project to build, test, and provide packages for the following environments (some environments may not be applicable to some projects):

• Raspberry Pi/BeagleBone/ARM SoC
• Cloud environment (AWS, Juju)
• Arduino

In general, in order to simplify both OpenHW and cloud deployments, we need to be better at providing Linux packages. For OpenHW platforms, in addition to delivering Linux packages, it is important to be able to cross compile for ARM, in order to provide pre-built binaries (compiling Mihini on a RaspberryPi is ~15 min, for example).

Embedded

• TODO: Does it make sense to provide pre-built OS images? Should Eclipse IoT projects provide Yocto recipes?

Raspberry Pi

• PROJECT-REQ ➜ Eclipse IoT projects MUST sign their Linux packages with Eclipse Fdn certificates
• IT-REQ ➜ It MUST be possible to sign Linux packages from build.eclipse.org/Hudson
• PROJECT-REQ ➜ Eclipse IoT projects SHOULD build Debian packages to allow easy installation on Raspberry Pi (Wheezy)
  • PROJECT-REQ ➜ Additionally, Eclipse IoT projects SHOULD provide Debian packages that include armhf binary
• PROJECT-REQ ➜ Eclipse IoT projects SHOULD make Debian packages available on the official debian/raspbian repo
• IT-REQ ➜ IT should provide templates of Debian packages, ready to be extended by projects
• IT-REQ ➜ In order to build native C/C++ binaries for the Raspberry Pi, build.eclipse.org MUST have a Raspberry Pi toolchain

• TODO: Need to investigate how to package Java apps for Debian. (see https://wiki.debian.org/Java/Packaging and http://pkg-java.alioth.debian.org/examples)

BeagleBone Black

• PROJECT-REQ ➜ Eclipse IoT projects MUST sign their Linux packages with Eclipse Fdn certificates
• IT-REQ ➜ It MUST be possible to sign Linux packages from build.eclipse.org/Hudson
• PROJECT-REQ ➜ Eclipse IoT projects SHOULD provide opkg packages to allow easy installation on BeagleBone Black (Angstrom)
• TODO: is it possible to contribute a package to the official BBB repo?
• IT-REQ ➜ IT should provide templates of opkg packages, ready to be extended by projects
• IT-REQ ➜ In order to build native C/C++ binaries for the BeagleBone Black, build.eclipse.org MUST have gcc-arm-linux-gnueabi Linaro toolchain.

Other Linux-based embedded platforms

• PROJECT-REQ ➜ Eclipse IoT projects MUST sign their Linux packages with Eclipse Fdn certificates
• IT-REQ ➜ It MUST be possible to sign Linux packages from build.eclipse.org/Hudson
• PROJECT-REQ ➜ Eclipse IoT projects MAY make Debian packages available on a repository hosted at Eclipse.org to allow easy distributions to embedded platforms other than the RaspPi running Debian (may require compilation from source by the consumers)
• PROJECT-REQ ➜ Eclipse IoT projects MAY make opkg packages available on a repository hosted at Eclipse.org to allow easy distributions to embedded platforms other than the BBB using opkg Package Manager – e.g. openWRT (may require compilation from source by the consumers)

• Do Java projects like SmartHome or SCADA require a native OSGi launcher for ARM? bug 431197 bug 406749
• Do we need (actual or virtualized) ARM platforms at build.eclipse.org to enable testing of the projects targeting ARM?

• NOTE: do we want to compile for other embedded environments? mips? avr32?

Arduino

We have some Eclipse IoT projects (Paho, Wakaama) that would benefit from being packaged as Arduino libraries. Packaging for the Arduino basically consists in providing the library source code and some code samples.

• PROJECT-REQ ➜ Every Eclipse IoT project that targets Arduino SHOULD provide in its download area a library enforcing the Arduino library packaging guidelines

Cloud environment (AWS, Juju)

As of today, the following Eclipse IoT projects could target cloud/server environments:

• Mosquitto
• Ponte
• Californium (HTTP/CoAP bridge)
• OM2M
• EclipseSCADA (?)
• Kura (?)

We want to make these projects easy to deploy in such environments. As a first step, it is safe to assume that as long as they provide Linux (or Node) packages, one can install them on virtually any cloud VM. On the longer run, we may want to encourage projects to provide Juju charms, Dockerfiles, Chef recipes...

AWS

Amazon Linux uses Fedora EPEL (Extra Packages for Enterprise Linux) to allow easy installation of extra packages.

• PROJECT-REQ ➜ Eclipse IoT projects SHOULD provide RPM packages on EPEL repo to allow easy installation in cloud environments
• PROJECT-REQ ➜ Eclipse IoT projects SHOULD provide docker images on the docker index repo to allow easy installation

Juju

• PROJECT-REQ ➜ Eclipse IoT projects SHOULD provide Debian packages on debian.org to allow easy installation in cloud environments
• PROJECT-REQ ➜ Eclipse IoT projects SHOULD provide Juju charms to allow deployment to EC2, OpenStack, Azure...

Other

• PROJECT-REQ ➜ Eclipse IoT projects using Node.js SHOULD provide milestones/releases in NPM (see npm publish)
• PROJECT-REQ ➜ Python projects SHOULD provide milestones/releases in PyPI (see PyPi register)
• PROJECT-REQ ➜ Lua projects SHOULD provide milestones/releases in LuaRocks (see Rock creation instructions)