We are setting up a production workflow and need a way to ensure devices heading our from our warehouse have all desired updates without our production staff needing to log into the balena cloud dashboard.
Ideally we would be able to set a desired OS and/or Supervisor version fleet wide and have the updates applied automatically as new devices come online and as we connect warehoused devices for updates before they are deployed to their install location. Is there a way to do this that I am not seeing in the documentation?
Alternatively, is there a way to trigger a supervisor and/or OS update from our application on the device or from the API? I see the os_version and supervisor_version on the deviceresource, but it is not clear if these fields are writable or not.
Supervisor updates are possible to set up for a device/fleet of offline devices. Once becoming online, the device will check that it has the right version and update the local supervisor. The same is not possible yet for OS updates, we are making progress on some improvements that will allow this in the medium term, but there is no ETA on the feature yet.
Regarding your second question, the easiest way to trigger an OS/Supervisor update from the an application container is through the SDK. Here are the links to the methods that you can use
Changing the values of os_version and supervisor_version on the device resource on the API won’t have any effect, as those represent last reported state of the device and have no influence on the target versions that are passed to the device.
Please let us know if the steps I shared above work for you.
Oh, one more thing. We have also recently published the autohupr balena block that maintains the device OS up-to-date. This might also be useful to you.
Queueing updates for existing offline devices only solves half of the problem. Ideally NEW devices would automatically update to the desired supervisor version.
In that case it does look like either the SDK or autohupr are your best bets to achieve what you want. Please let us know if you make any progress with this
autohupr looks promising. It is intended to run on the device, correct? It looks like we could easily update it to accept the OS version from an environment variable, which would allow us to set our desired version fleet wide. We should be able to do similar with the supervisor.
It is a shame you don’t have a golang SDK, as that is the primary language we use on our devices.
yes, autohupr is intended to run on the device. If you do add support for installing a specific OS version, do not hesitate to create a PR on the autohupr repo or create a fork of the block in balenaHub.
Regarding the golang SDK, it has been requested before, however we don’t have any immediate plans to support an SDK for that language yet. We have made note of your request, as it helps us prioritize new features.