Should the balena app commit # be the same as the deploy release?
My latest commit for a multi-container project is not getting pushed to devices.
Preloading the project works (but then gets overwritten with what open balena believes is latest.)
Just for fun I deploy the exact same project 24 hours later. This time the catch-connect container showed all of the build steps instead of stopping after Preparing...
Why would the deploy behave differently?
This release still does not get pushed to devices.
Does it have something to do with the display container not being tagged as latest?
the build process is happening on your workstation, not in openbalena, so a failure here could be related to your setup.
the device will only be “pushed” an update if the VPN is connected, or once it connects back to the openbalena server to checkin (approx. every 10mins)
the openbalena stack is still not considered production-ready and we cannot recommend it for a production deployment.
Could you confirm the following:
when your openbalena instance was last updated, so we can get an idea of the service versions you’re running
that you have deployed any application successfully with this openbalena instance, or is this your first attempt
the output of the following command:
balena devices
Sorry if this takes a while to resolve, there are a lot of moving parts.
deployed a simple multicontainer application to “test-app”
watched the supervisor logs to see it get triggered straight away
confirmed it is operational
Looking at the device list you sent over (thanks, btw) it showed only a single device as online, so I will assume you’re testing with that one. I think the next step will be to get some ideas from the logs of that device, so if you SSH into that Pi and run journalctl -u resin-supervisor -fn100 you should see the last 100 or so lines of supervisor logs. If you leave it running then it will stream in any new log entries.
If you do this, then do another deploy then see what happens in the supervisor logs after it completes. I saw it instantly start to pull the services and start them.
See if this shows anything useful and post back here if you spot anything that looks weird.
@patrick also just to answer your earlier question about release/commit IDs; when you do a balena deploy operation you should be presented with a release value. This is held on the device record as commit and accessible via the Supervisor API where it is also commit. See the screenshot attached for this, highlighted in red.
FYI: the web page shown is my test app, running on the device, and using the Supervisor API to acquire the values.
30.01.19 14:50:39 (+0100) Service is already running 'catch-connect sha256:4e44e680cd136cbf8abd2ef62583fe6b9101243dbb114bc0454ca648ca634748'
30.01.19 14:50:39 (+0100) Service is already running 'display sha256:c07ec8a5dfe4314a83a9e246643f21726dfc41c9b6fe0c9cd2dff0cb5a20ac08'
30.01.19 14:55:53 (+0100) Killing service 'catch-connect sha256:4e44e680cd136cbf8abd2ef62583fe6b9101243dbb114bc0454ca648ca634748'
30.01.19 14:55:53 (+0100) Killing service 'display sha256:c07ec8a5dfe4314a83a9e246643f21726dfc41c9b6fe0c9cd2dff0cb5a20ac08'
30.01.19 14:55:58 (+0100) Service exited 'catch-connect sha256:4e44e680cd136cbf8abd2ef62583fe6b9101243dbb114bc0454ca648ca634748'
30.01.19 14:56:02 (+0100) Killed service 'catch-connect sha256:4e44e680cd136cbf8abd2ef62583fe6b9101243dbb114bc0454ca648ca634748'
30.01.19 14:56:03 (+0100) Deleting image 'registry.balena.catchtechnologies.com/v2/466b565767ca0bc444d3b8aec23be863@sha256:ddb0597e7ce5d3d1576a7260e8c0c25cca763ae257a95dee40fb3692bb4dbcc0'
30.01.19 14:56:08 (+0100) Service exited 'display sha256:c07ec8a5dfe4314a83a9e246643f21726dfc41c9b6fe0c9cd2dff0cb5a20ac08'
30.01.19 14:56:17 (+0100) Killed service 'display sha256:c07ec8a5dfe4314a83a9e246643f21726dfc41c9b6fe0c9cd2dff0cb5a20ac08'
30.01.19 14:56:18 (+0100) Deleted image 'registry.balena.catchtechnologies.com/v2/466b565767ca0bc444d3b8aec23be863@sha256:ddb0597e7ce5d3d1576a7260e8c0c25cca763ae257a95dee40fb3692bb4dbcc0'
30.01.19 14:56:18 (+0100) Deleting image 'registry.balena.catchtechnologies.com/v2/2cc24bdc82667c2b07351526eafcde9c@sha256:f3a61cde8bb3e153719a246788c575ef4b69143d5afe3b512c947d04b27c25c9'
30.01.19 14:56:22 (+0100) Deleted image 'registry.balena.catchtechnologies.com/v2/2cc24bdc82667c2b07351526eafcde9c@sha256:f3a61cde8bb3e153719a246788c575ef4b69143d5afe3b512c947d04b27c25c9'
30.01.19 14:56:23 (+0100) Installing service 'display sha256:494c109ad3567acfa22db8b08a7bb5b1116c9ccc6af15331f1ba4c5ce2a790fa'
30.01.19 14:56:34 (+0100) Installed service 'display sha256:494c109ad3567acfa22db8b08a7bb5b1116c9ccc6af15331f1ba4c5ce2a790fa'
30.01.19 14:56:34 (+0100) Starting service 'display sha256:494c109ad3567acfa22db8b08a7bb5b1116c9ccc6af15331f1ba4c5ce2a790fa'
30.01.19 14:56:42 (+0100) Started service 'display sha256:494c109ad3567acfa22db8b08a7bb5b1116c9ccc6af15331f1ba4c5ce2a790fa'
30.01.19 14:56:42 (+0100) Installing service 'catch-connect sha256:6819fd35d17517150164d43dce1fb47d60c964773b9e5098353c399c616328cc'
30.01.19 14:56:46 (+0100) Installed service 'catch-connect sha256:6819fd35d17517150164d43dce1fb47d60c964773b9e5098353c399c616328cc'
30.01.19 14:56:46 (+0100) Starting service 'catch-connect sha256:6819fd35d17517150164d43dce1fb47d60c964773b9e5098353c399c616328cc'
30.01.19 14:56:49 (+0100) Started service 'catch-connect sha256:6819fd35d17517150164d43dce1fb47d60c964773b9e5098353c399c616328cc' ```
And then it starts printing logs from my app . So the apps are downloading, just not the version we need.
the openbalena stack is still not considered production-ready and we cannot recommend it for a production deployment.
But the OS is production ready. The plan is to release the OS configured for our open balena instance and preloaded with an app that locks out updates.
@richbayliss Thanks for the commit/release explanation.
So they should be the same, right?
The deploy and release numbers do not match for me.
Here is my current deploy output…
[Info] Compose file detected
[Info] Everything is up to date (use --build to force a rebuild)
[Info] Creating release…
[Info] Pushing images to registry…
[Info] Saving release…
[Success] Deploy succeeded!
[Success] Release: 19bc67fa2f3256944a76d92cf8de3ea5
and the app output…
$ balena app 1
== CATCH CONNECT RPI3
ID: 1
DEVICE TYPE: raspberrypi3
COMMIT: 3792751532d6788ddb6505f7f0b91d09
and the online device…
$ balena device b947ff1
== OLD FOG
ID: 31
DEVICE TYPE: raspberrypi3
STATUS: idle
IS ONLINE: true
IP ADDRESS: 192.168.1.58
APPLICATION NAME: catch-connect-rpi3
UUID: b947ff12b345db61661dc554280cbb7a
COMMIT: 3792751532d6788ddb6505f7f0b91d09
SUPERVISOR VERSION: 9.0.1
OS VERSION: balenaOS 2.29.2+rev1
the device will only be “pushed” an update if the VPN is connected, or once it connects back to the openbalena server to checkin (approx. every 10mins)
does the VPN need a port other than 443 to be open?
Yes they should, so if yours are different then something is not working as expected when the release is made. Could you confirm that you have the latest CLI version installed; mine is 9.11.2 for reference.
@patrick something else which might help us here; could you run the following command to query the API for the release you’re being told was successful…
@patrick So I have managed to replicate your experience but it has required me to change some values on my application resource via the API to do this…
If you set the flag should_track_latest_release to false via the API then whenever you deploy a new version it will not be pushed down to the device, and the commit value doesn’t update (just as-per your first post)
Could you run the following command, just to make sure the application isn’t somehow pinned to an older version: