I am using a microservices type app, in a Raspberry Pi 3. The version of the ResinOS is 2.12.5+rev1 (prod).
I pushed the images to the app using resin deploy app_name (where a docker-compose.yml exists), and the images started to download in the device.
First question: I am using the fleet var: “RESIN_SUPERVISOR_UPDATE_STRATEGY”: “kill-then-download”. However, the downloads started but the services didn’t stop: only when the image has been downloaded, the service is stopped and then installed. Shouldn’t services be stopped and then download and install the images?
Because of memory issues, the device was rebooted (while some of the images were being downloaded) because of the functionality of one of the services (using the supervisor API). At the end, all the images has been downloaded and installed, but one of them seems to be blocked: it tries to download the image all the time, and the following error is printed on the logs screen:
Failed to download image 'registry2.resin.io/v2/XXXXXX@sha256:XXXXXX' due to 'failed to register layer: open /var/lib/docker/aufs/layers/XXXXXX: no such file or directory'
Second question: whan can I do to repair that error?
The second error that is shown implies that the docker directory has become corrupted. The easiest way to deal with this (if you don’t mind redownloading your application containers and the supervisor container ) is to run the following on the host OS:
Hi @jcozar! In resinOS 2.12.x (with resin-supervisor 7.x), update strategies are defined per-service, so they’re no longer defined with configuration variables. Instead, you’ll need to use an io.resin.update.strategy label in your docker-compose.yml. Docs: https://docs.resin.io/reference/supervisor/docker-compose/#labels
thank you very much @CameronDiver! I tried your commands and it worked perfectly.
And also thank you @pcarranzav! I misunderstood the doc: I though that both possibilities (using the label and using the device conf var) were possible in microservices apps. I like this approach more because you can set the strategy individually, but just as a first trial I used (incorrectly) the device conf var approach.