Hey Rich,
Yeah, that’s fair. Right now we have most of our customer devices tracking the application, and using the update lock to prevent the supervisor from resetting stuff when they’re actively navigating. That’s working for the moment, but we’re just thinking ahead design-wise. In hindsight, I wonder if as you said, the supervisor is actually not really the right way to get this information anyway.
For the most part, downloading updates automatically but holding them off via update lock may work for some users. That being said, we want to have the option to not do that though since the automatic download could have a big impact on bandwidth and our container deltas are often quite big. Most of our users are connected via cell, and when they’re navigating that definitely needs to take priority over downloading a release. Right now pinning appears to be the only way to prevent that. I don’t believe there’s a way to tell the supervisor to check for updates but not download them. It’s all or nothing, no?
We also don’t want to change software versions unexpectedly if they’re actively testing something, particularly if the change includes something that may not be backwards compatible. Don’t want to have any repeatability issues.
From https://forums.balena.io/t/update-when-user-interacts/, our plan was to use pinning to resolve this. Basically, instead of tracking the application, devices would be pinned to some release. The software would check if there was a new release available by seeing what the application was pinned to vs what the device is currently running. We tag releases with a version number since the release hashes don’t have any notion of semver, so our software would have to query the release tags via the Python SDK (and balena-api permissions).
Does that sound about right?
Thanks,
Adam