-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential improvements for lepidopter #63
Comments
Nice! I think one way to address updates could be having the core functionality packaged all together into a Docker image, such that for us updating is just swapping images. In turn, this would enable us to choose someone such as resin.io for managing devices. I am now wondering if it would be technically feasible to have all the packaging inside of a docker image, or whether there are Raspberry specific files and dirs that Lepidopter needs to access. |
I had a look at resin-os, yoctoproject and mender; an over-the-air software updater for connected Linux devices. It seems that these projects had already solved a number of the issues and burdens that we are going to face in the future. |
After some research it seems that there are a number of software projects that perform OTA upgrades in various ways. The OSTree related projects page has an excellent for most of this software: Additionally Qt (based on OSTree) seems to handle OTA upgrades: https://doc.qt.io/QtOTA/ |
Adding the evaluation (WIP) spec #69 for OTA upgrades to our conversation. |
I was just looking at what resin.io are doing for managing big fleets of embedded devices and it seems like there are some things we can learn from them.
https://resin.io/how-it-works/
Basically they have a very lightweight base OS image https://github.com/resin-os that is based on yocto (http://www.yoctoproject.org/). Then everything is an app that runs inside of a docker container. When they need to provision updates, what they do is they push a new docker image to the docker repositories and then pull it in from the devices.
The devices are managed via a VPN that allows them to reach devices behind NAT.
In particular they have a supervisor that is written in go and based on docker for running "apps" on their devices:
A captive portal like thing for connecting devices to wifi networks:
The text was updated successfully, but these errors were encountered: