Resolution: Won't Do
Affects Version/s: None
Fix Version/s: None
Moved specific design proposal here to not delete any data in the original epic.
The goal for the update modules is to make the design/architecture as simple as possible to let the Mender team and the external contributors understand and contribute easily.
The update module will be split into two parts: Mender-update-library and Update module itself.
Mender-update-lib is a small library (we will start with Go, but will provide a C version later on; some other options might be possible as well, with Python being one) taking care of the whole communication/interaction with the Mender server. It will be the Mender device API consumer (https://docs.mender.io/1.5/apis/device-apis) handling authentication, inventory, status, and check-for-update requests.
The other part is the Update module itself. It's main job is performing the actual update (whether this will be the whole rootfs update, delta update, proxy update or any other kind of update). The Update module can also call the existing installer (we assume in many cases there are a ways of upgrading the software once the new image is delivered to the device).
In order for the two to communicate we will need a:
- network stream - will contain the update payload, that will be used for installing the update; most probably this will be implemented as a pipe
- status channel - optional for sending a status back to the Mender-updater-lib; it might be implemented as a unix socket
- update metadata - a medium for sending update metadata to the Update module; might be implemented as a file, that will store all the update information in agreed format
Mender-update-lib will provide all the needed information to authenticate to the Mender server (containing authorization data), will be collecting and sending inventory data (at a minimum we need to send the device type and the currently installed update). Once the check-for-update request will return new update information (https://docs.mender.io/1.5/apis/device-apis/deployments#produces) the Update module will be called providing at the minimum a stream containing the update payload and the update metadata. Optional status channel might be open (unix socket) for collecting additional status information (and logs) from the update module. Once the update module is done with installing the update the status will be read indicating the success (0) or failure (!0) of the update process.