Yes, the pinned approach is what I am going for and I have my basic setup working.
Since the change is less immediate as you put it, I was trying to have the device itself detect when a download is in progress , but I ran into this problem: Supervisor response for v2/applications/state is incorrect
But thx for the discussion in this thread, I will consider it closed for now, and again I apologize to @bversluijs for what ended up as hijacking this thread.
I havenāt had the time to test some update methods, but all the comments are useful for new thoughts!
Iām currently figuring out how to set the lockfiles on all my containers, or isnāt that necessary? Because I have a multi-container application and just 1 container has direct interaction with the frontend. It is possible for that container to set the lockfile at /tmp/balena/updates.lock, but other containers (e.g. a Redis or MySQL container), itās really hard to set the lockfile, quite impossible. Is there an example available on how to do this?
And @krix, no worries about hijacking the thread! It really helps that some other users are also busy with implementing an other update system where the user has to interact to update.
But I donāt seem to fully understand whatās meant by the pinned approach, so help me out here as Iām summing up the required steps:
When device is registered with cloudBalena, it downloads the newest available release and pins itself to that release ID.
The device checks if an update is available via a custom API thatās linked to balenaCloud.
If an update is available, the user can accept the update and the custom API sets the pinned release for that device to the newest available release. The device sets the lockfile until the download is completed.
When update is completed, the device removes the lockfile and sends a request to /v1/update to initiate the update to be installed.
The creation of a custom API is no problem, but Iād like to fully understand the steps and requirements before spending my time on a custom API. All the posts are great, but Iām really losing the oversight on what steps has to be taken and whatās the best approach on how to do it. But nevertheless, thanks for that @pdcastro & @CameronDiver!
For me the Lockfile strategy works so far. The image is not being updated automatically anymore but when hitting the supervisor update route (v1/update) with a body of
{
āforceā: true
}
the update still does not start right away. it takes sometimes even a few minutes until it starts. Even tho the containers have all been downloaded already. What am i doing wrong?
Is there anyway to see the current update progress? To see whats going on or at least see a log or something? Hitting the update route with a post request does not seem to trigger the update right away for some reason.
the reason this can happen is that the supervisor communicates with the state endpoint to learn about new releases it should download and apply. This is checked periodically and there is also some backoff logic built into it to reduce bandwidth and power usage from the device. The lockfile serves as an override for this process; once its removed the supervisor does not try right away, but simply waits for the next scheduled check.
We are currently working on changing this so that once the lockfile is removed, the backoff is ignored and the update is applied right away.
You can track progress on the supervisor issue https://github.com/balena-io/balena-supervisor/issues/977
I hope this is clear, let me know if you have more questions
Just to confirm and to let you know. We are not deleting the lockfile but overwriting it with POST request and the
{
āforceā: true
}
That seems to work because the update starts after a few minutes. But we never removed the Lockfile. Just to let you know, not sure if that was clear.