Update when user interacts

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.

Hi all,

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:

  1. When device is registered with cloudBalena, it downloads the newest available release and pins itself to that release ID.
  2. The device checks if an update is available via a custom API thatā€™s linked to balenaCloud.
  3. 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.
  4. 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.

Hello, which Balena OS version are you using?

Hello supervisor 9.11.3 and os version 2.31.5+rev2

Hello Torben,

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

1 Like

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.

Thanks @Torben , that is interesting. I would expect if you are hitting that endpoint it would start doing the update instantly as Cameron mentioned.

Yep i would too and by the way i made sure the update is fully downloaded before i hit the route.

It definitely sounds like it should be instant, so we will have to take a look at this and see what is causing the delay. Sorry about that.

1 Like

Oh no worries! Thank you for looking into it!!

I created an issue to track it here https://github.com/balena-io/balena-supervisor/issues/980 , so you can add more info there if you are up for it. Thanks for raising it!

1 Like

This was resolved on Jun 26 by mwohlert