In-place upgradable components through in-band channels

[gmerlino]

We need to be able to upgrade code piece-wise, especially critical parts, such as the WAMP communication subsystem, without disrupting the reachability of the remote boards, at all times.

This translates into:

• in-place code replacement, where needed
• in-band file transfer and upgrade

including fault-tolerant upgrades, such as, e.g., secondary WAMP client being up and working before shutting off the primary.

Self-contained executables and plugin-based logic is another essential enabler for this issue.

[flongo82]

In the OpenStack version of the IoTronic we are introducing the concept of Lightning-rod module.

The Lightning-rod in its initial configuration should be as thin as possible, just being able to connect to the WAMP router and receive new modules to load. Each advanced functionalities (e.g., networking, plugins, drivers) should be implemented as a separate module. Moreover, the version of the Lightning-rod that has been implemented to interact with the OpenStack version of the IoTronic has already been implemented so that there is a main process that spawns a child process and monitor its life-cycle. If the child process crashes for any reason it is respawned. Moreover, when a change in the configuration file is triggered by the Cloud, the child process is killed and respawned so that the new configuration file is loaded.