Robert: You should be thinking more of CI/CD. The main page at
mender.io says"We have created an infrastructure that allows us to do
automated unit, acceptance and integration tests on each code change we
make to the product. We run tests on both virtual and physical devices."
When some software change has passed its integration tests it gets
deployed automatically or semi-automatically. You need to ensure that
all devices get updated to match the configuration which was tested. The
complexity of an rpm package management system is working against you. I
would invoke the KISS principle, doing everything the simplest possible
way. Also think of the term "idempotent": a service which can be called
one or many times giving the same result.
Yes, you could replace the entirety of the installed OS. You would tag
the releases, and your git keeps track of what is in each tag. How well
does this scale? Maybe well enough.
But I have no skin in this game. You decide.
cheers -- Rick
On 2/17/20 4:39 AM, Robert P. J. Day wrote:
for an upcoming project, one of the longer-term goals is to
establish a secure OTA update system for potentially hundreds or
thousands of remote (internet-connected) devices, which might need to
be updated en masse identically, or updated individually.
i'm currently collecting examples of available solutions
(https://mender.io/, https://sbabic.github.io/swupdate/swupdate.html,
and so on), and the current custodians of the system have already had
animated discussions as to what they think would work, and what
properties it should have.
on the one hand, there is the notion of a package-based system,
where one can download and update individual packages (rpm, apt, ipk,
etc...) as necessary. the ostensible downside to this is that, over
time, it's entirely possible that different remote systems will have
different updates applied and slowly get out of sync with one another.
is that a big deal? well, if you're a linux person, no, since we're
used to updating packages as we see fit. however, embedded developers
who are used to installing a single, monolithic executable would argue
that the downside is that there is no single identifier for the
software currently running. if one asks, "what version of the OS are
you running?", there is no single identifier that means anything --
you would need to examine the entire manifest of installed software.
on the other hand, if the only supported OTA update is to replace
the entirety of the installed OS, you could theoretically version
every single possibility, but that gets cumbersome.
i could go on, but has anyone here worked with such a system and be
willing to describe their solution? i'm just collecting possibilities
to be further debated.
rday