Open roman-mazur opened 5 years ago
[roman-mazur] This issue has attached support thread https://jel.ly.fish/#/support-thread~277e09f0-b4a7-4779-b30a-747179955703
I've clarified a little bit, this problem exists because the supervisor attempts to pin itself to the previous application after being moved.
@CameronDiver should we track the cloud API issue separately? After devices were moved to a different app, they still referred to the previous app releases.
I'm not 100% on what you mean @roman-mazur ? Which specific cloud issue?
@CameronDiver after moving a device from one application to another, the device release pins were referring to a release from the old app - this sounds like a bug in the API impl. We had to "re-pin" the devices first, and then clean the supervisor state to make it fetch new releases info.
This doesn't really seem like an API issue. The supervisor has to specify a release ID when pinning a device, if that release ID is wrong, then there's nothing really the API can do.
After a device with preloaded containers is moved to a different app before it boots, the supervisor fails with the following log:
Workaround included:
/mnt/data/apps.json
, the database, and restarting the supervisor)See https://github.com/curcuz/batch-supervisor-restart/blob/master/task.sh#L22