balena-supervisor
balena-supervisor copied to clipboard
balena-os
When moving between two fleets, Supervisor isn't able to stop services on old fleet that have a lockfile
As such, the device after moving to the new fleet will still keep the old service(s) running, and error about update locks for the old service being present.
Reproduction for this behavior can be found here: https://github.com/balena-io-experimental/leftover-lockfile-on-move
As the Supervisor should remove all artifacts from an old fleet upon moving to a new fleet, it makes sense that the Supervisor should force the removal of services on the old fleet even if a lockfile is present. However, this is debatable -- should the responsibility fall on the user to clean up artifacts from their old release and responsibly manage lockfiles, or should the Supervisor handle it?
What happens if you have multiple services? I would expect that no services get killed right?
I think this is the correct behavior, the locks need to be managed by the user app, we cannot risk ignoring a lock (what if the device is an active vehicle?)
What we maybe could do is check the state of locks earlier in the process for application removal and reject the target state if that's the case (I'm not totally sure of the right mechanism here).
What happens if you have multiple services? I would expect that no services get killed right?
Yes, no services get killed.
The target state rejection makes sense and is more safe, so I agree. As such, I'm linking this issue to https://github.com/balena-os/balena-supervisor/issues/1743 👍🏼
Hey @cywang117 @pipex I agree with what said above, what we could do perhaps is to add a check in the dashboard when the user tries to move a device. Checking if a lock exists from the dashboard, if exist then warn the user that a lock has been found and that it should be removed if they are sure the services can be safely killed.
I'm not too sure though that the lock can be easily detected from the dashboard, I honestly don't remember atm 🤔
