I'm currently investigating a options for a linux-based operating system for some kind of embedded system that we are working on. As we really want some atomic update mechanism that helps avoiding to brick the device during updates and as it would also be helpful to deploy some applications in form of docker containers I'm currently taking a look at project atomic. Therefore I would like to ask here if there are some experiences available for using Project Atomic in such a scenario, or if it would be even a recommended solution or not.
Some short overview about our use-case and requirements:
- We are looking at some kind of Intel NUC class hardware (so it's not deeply embedded, boots with standard UEFI instead of a uboot &co, ...)
- Yet we have a little bit more special hardware attached to it, and probably need a custom Kernel. We definitely have some in-house kernel-modules that we need to deploy.
- Software will only come from us in form of new releases. No 3rd party apps
- The device should only be updated when we issue a new release
- The device will not be always-online.
- Updates should cover the whole system, there shouldn't be individually updated apps.
- Updates should be possible through flash drives with update files on them as well as (probably later on, as we don't have the necessary infrastructure yet) over the internet.
My first idea on how to solve this with project atomic (after reading through the available documentation) was to create a new ostree (with rpm-ostree) during our build process, get that ostree in some kind of archive to the device, put it there into a local webserver, and update from there. It think this seems to be in scope of Project Atomic?
What I am not sure about is whether I can really create completely new and isolated os trees with each build, and install them through this method. The current main scope of Atomic seems to be more like I start with Fedora 23v1 and continually update to newer Fedora 23 versions (but never to 24 or CentOS), and in order to apply updates a need an ostree repository which contains all update steps in it (and not only the snapshot of the target). At least that's what the atomic upgrade command and the GUI in cockpit are suggesting. I'm not to keen on distributing all revisions of my software for each update and also would like to avoid to require history of old update firmware builds for building the latest revision.
Distributing a completly new ref in each update seems to solve that, but I don't understand rpm-ostree enough to understand if that will work or if that will only bust the system. There might be refs which have content that is 99% identical with the last version, but there might also be one that need to be completly new. As a test for that I tried to ... (more)