Ok - this may be an odd one: I’m upgrading one of our IoT applications to use Resin.io. This application has normal Ethernet access sometimes, and that works perfectly well. At other times - depending on the individual device in the fleet - it may go without normal Internet access for months at a time. When it is without traditional access, it periodically has a high-speed connection through a custom radio system. It can receive files during that period.
In our current setup, if there is an upgrade for the firmware (application in this case), we can overwrite the files as needed and restart the firmware. I’m trying to do a similar thing with Resin.io.
The perfect scenario would be something like:
The radio host checks the Resin API to see if there is a new version - similar to how Supervisor does now, I would guess.
If there is a new version, the radio host downloads it.
The radio host connects to the device in the fleet and pushes the file(s) it pulled from Resin somewhere.
The device (once it has checked the integrity of the file - we can use the same signature system we already have) notifies the Supervisor that it should upgrade, or the Supervisor somehow automatically decides that when the file delivery is complete.
Supervisor does what it normally does, picking up with the application install instead of application download.
Is this possible? Thoughts?
Again, totally awesome system. It has already saved loads of time in a new project we used to experiment with the framework. I’m now enjoying upgrading some of our other fleet apps.
I’m not sure I totally understand what you require. At the moment if the internet connection is interrupted the supervisor will keep running and periodically polling for updates so it should automatically detect that it has come online again and pull any available updates.
Is the radio host not an IP-based connection from the perspective of the device?
No - the radio host is not an IP connection at all. It is a pure serial interface, and PPP isn’t available. Files are actually transferred using zmodem and friends. The file transfer is already in the application layer and in use for other functions. I need to leverage that, in this case, to allow upgrades of the application in the field when the device’s only access to the outside world is when the data collection radio host arrives to grab existing bulk data and do the upgrades. (The devices actually have some limited non-IP connectivity all the time via satellite. We use that sparingly - for alarms and such - because it is crazy expensive. We definitely don’t want to try to update over that.) Again, a lot of the devices have constant Internet access, and they won’t have an issue, but well over 1/3 of the fleet are deployed in environments where bulk connectivity only comes via radio host with a week or longer between physical maintenance visits to the site - and that can be the case for many months or a few years.
Sorry for my slow response - I’ve been out of the office.
Yes. I have seen both of these resources, and the supervisor-api has a lot of useful things for this. There are really two things missing in order to perform the update in a disconnected manner.
First, a way to download whatever package or image or container backup or other file or files that the supervisor downloads from the central Resin system after the Git build. The radio host would do this to get the latest version of the application on behalf of the remote system (possibly a day or so in advance depending on schedules and site connectivity). Once that is done, the radio host has the package that the supervisor that each disconnected device needs to upgrade.
Second, the application on the device needs a way to give that package to the supervisor. The supervisor-api has a way to ask the supervisor to update, but since the device doesn’t have an IP connection to the outside world at that time, it will attempt to download and that will fail. If, somehow, we can give the package the radio host has downloaded to the supervisor so it doesn’t have to download it, only install it, then I think we are good. We already have a way to get anything we need from the radio host to the application on the device.
Does that help clarify further? This is such an awesome system. I really want to see it used across our whole fleet, and this seems to be the only thing standing in the way of that goal.
The problem of providing the bulk of an update via a non-IP route is certainly interesting, and one which I can imagine being useful to a modest quantity of fleet managers. There are a couple of interesting challenges around protecting against malicious agents, but there are some pretty well established solutions there in the form of checksums and public/private signing.
However, this is not a small body of work and the information from the internal conversation is that it is not immediately on our roadmap.
