Hello folks, looking for some feedback on the new getting started guide, which is part of this openBalena PR.
We’ve made some fairly major structural changes and updated all the deps.
Cheers!
3 Likes
Hi,
I noticed the minimum version requirements have been updated.
The current release of openBalena has the following minimum version requirements:
- balenaOS v5.2.8
- balena CLI v18.2.2
If you are updating from previous openBalena versions, ensure you update the balena CLI and re-provision any devices to at least the minimum required versions in order for them to be fully compatible with this release, as some features may not work.
I’ve been using API version 20.1.14 with some devices still running Balena OS 2.115.x and haven’t encountered any issues so far. Do you know of any specific cases where something broke with these older versions? Or are the new minimum requirements primarily a precautionary measure?
Additionally, I think it would be helpful to have a section about upgrading to newer versions, This section could also include information about necessary changes during the upgrade process. For instance, I recall that the TRUST_PROXY variable needed to be set for the API in a previous update.
Kind regards,
Maurits
Do you know of any specific cases where something broke with these older versions? Or are the new minimum requirements primarily a precautionary measure?
There really wasn’t a lot of science behind this, we just took the currently latest version stamp and put it into the docs. The automated tests alway use the latest version of balenaOS to test with.
So, while we don’t test with previous versions as it would be expensive (we spin up AWS/EC2 instances for each run), they probably will work up to a certain point, 2.100+ should be safe, but testing is recommended prior to upgrade.
Additionally, I think it would be helpful to have a section about upgrading to newer versions, This section could also include information about necessary changes during the upgrade process. For instance, I recall that the TRUST_PROXY variable needed to be set for the API in a previous update.
This is all now codified in the single composition, along with other items, such as REDIS_IS_CLUSTER, I’ll add a note about upgrading, but since we aren’t actively supporting real openBalena deployments anywhere, we’ll look to the community to perform the ultimate upgrade test…
Thanks for the quick reply.
This is all now codified in the single composition, along with other items, such as
REDIS_IS_CLUSTER, I’ll add a note about upgrading, but since we aren’t actively supporting real openBalena deployments anywhere, we’ll look to the community to perform the ultimate upgrade test…
I think it’s important to highlight this in the documentation. New people might assume the master branch to just work and it can help set the right expectations when trying out OpenBalena.
Over the past year, I have upgraded several OpenBalena instances, starting from version v0.209.2 all the way up to v20.1.14. I have taken notes during these upgrades and I’m more than willing to contribute them to some sort of community upgrade guide.
Over the past year, I have upgraded several OpenBalena instances, starting from version
v0.209.2all the way up tov20.1.14. I have taken notes during these upgrades and I’m more than willing to contribute them to some sort of community upgrade guide.
We’d love that. I suggest we create another link off the main README.md called “Upgrade/migration guide” or something to that effect, cleanup and put your notes there.
Great to hear. I’ll look into it when I have some free time
Hy
is there some progress of the new helping page?
We try to upgrade from a old open-balena server to the latest one.
It seems there are huge differences between this versions (we have installed the 2 year old one, without the new Makefil)
The new makefile is creating new volumes for every container.
is it possible to copy the content from the old volumes to the new ones?
Is there a upgrade path to migrate the old version to the newest one?
we have this container version installed.
a simple git pull and make up is not possible anymore…
balena/open-balena-api:v0.209.2
balena/open-balena-registry:v2.25.3
balena/open-balena-s3:v2.13.10
openbalena_cert-provider
redis:alpine
balena/open-balena-db:v5.1.2 openbalena_db_1
i found a solution and was able to upgrade our open-balena server from 3.8.2 direct to the latest 4.1.x version.
this was my way. Maybe also yours.
open-balena upgrade path from 3.8.2 to latest 4.1.x
At first make a SNAPSHOT or at least a backup of your server!
Be sure you can restore your backup!
Create a server-clone, to be sure, the upgrade path is working at your system.
This is the path, which is working on our environment.
After the upgrade use the docker log --follow <container> funciton to detect error messages in the api, registry, haproxy or db container.
update server and install required packages
sudo apt-get update && sudo apt-get install -y make openssl git jq
switch to sudo balena user
sudo su balena
cd /home/balena
rename open-balena root folder, to correct prefix
Otherwise the command ‘make up’ will create new volumes, the prefix of the container volume is the name of the installation folder
The migration only works if the new system uses the old container!
mv open-balena openbalena
cd openbalena
clean up your changes
git restore compose/version
now upgrade the open-balena server to latest version
git pull
define your Main-Url of the server
export DNS_TLD=<your-domain>
Prepare docker-compose file!
nano docker-compose.yml
change the volume names to old pattern
to this by the volume definition and for the s3 and db container
db-data => db
s3-data => s3
prevent crazy load in api container
sometimes the api tries to refresh the device list.
some devices are in private repos and open-balena have no premission to show the details.
a lot of error messages appears in api container and is not available for some minutes
happens mostly by generating a new device config.
To activate a devicetype filter add this to API-Container Environment Variable section:
CONTRACT_ALLOWLIST: arch.sw/armv7hf;arch.sw/aarch64;hw.device-manufacturer/asus;hw.device-family/tinkerboard;hw.device-type/asus-tinker-board-s;hw.device-type/asus-tinker-board;hw.device-type/raspberrypi3;hw.device-type/raspberrypi4-64;sw.os+hw.device-type/ubuntu@lunar+raspberrypi3;sw.os+hw.device-type/ubuntu@jammy+raspberrypi3;sw.os+hw.device-type/alpine+raspberrypi3;sw.os+hw.device-type/debian@sid+raspberrypi3;sw.os+hw.device-type/debian+raspberrypi3;sw.os+hw.device-type/ubuntu@focal+raspberrypi3;sw.os+hw.device-type/ubuntu@focal+raspberrypi4-64;sw.os+hw.device-type/debian@sid+raspberrypi4-64;sw.os+hw.device-type/alpine+raspberrypi4-64;sw.os+hw.device-type/debian+raspberrypi4-64;sw.os+hw.device-type/ubuntu@lunar+raspberrypi4-64;sw.os+hw.device-type/ubuntu@jammy+raspberrypi4-64;sw.os+hw.device-type/debian@bookworm+raspberrypi4-64
Disable registry cache and force region to us-east-1 for s3 container
COMMON_REGION: us-east-1
REGISTRY2_CACHE_ENABLED: 'false'
repair make file
there is a faulty jq parsing command
nano Makefile
go to wait: -section and repair jq query
jq -r '.Health' => jq -r '.[ ].Health'
now we can finaly start the container
make up
allow migration of database
the db container is able to migrate the postgres database from 14 to 16 automatically.
But the API Migration Script is faulty.
The script 0074-normalize-release-contract is crashing the startup.
You have to delete this file at every ‘make up’ command!
go into api container and delete migrations file 0074*
docker exec -it openbalena-api-1 /bin/bash
rm src/migrations/0074-normalize-release-contract.async.ts
exit
docker restart openbalena-api-1
delete some wrong database entries
sometimes you see in the log (docker logs --follow openbalena-api-1) a strange output.
Error loading application config MigrationError: Failed to execute ‘balena’ model from ‘undefined’ due to: operator does not exist: boolean <> integer
To get ride of this message connect into the postgres database and delete some constraints entries from the release table.
docker stop openbalena-api-1
docker exec -it openbalena-db-1 /bin/bash
psql -U docker -d resin
show table details
\d+ release
delete wrong contraints check from release table => modify the relase$
ALTER TABLE release DROP CONSTRAINT "release$69zgYrVSJaN1avGiEeipPlJ9/lMKzOIt3iMPF6u/6WY=";
ALTER TABLE release DROP CONSTRAINT "release$RcddhgkY+99IgKXAUId7Q3iN4WylzgAxSFiF+JvyRiY=";
if you changed the domain url, tell the database where the images of your fleets are stored now.
UPDATE image SET "is stored at-image location" = REPLACE("is stored at-image location",'registry.<old-url>','registry2.<new-url>');
UPDATE release SET "composition" = REPLACE(composition::Text,'registry.<old-url>','<new-url>')::jsonb;
\q
exit
restart api container
docker start openbalena-api-1
check for unhealthy container and restart them
docker ps
docker restart openbalena-vpn-1
finalise the upgrade
if you have used a selft signed cert, i have no solution.
we switched to cloudflare.
only so our old devices are able to reconnect again.
i found no way to use the old self-signed certificates (we changed the url…)
sudo su balena
cd /home/balena/openBalena
add cloudflare credentials
nano .env
ACME_EMAIL=<your-user>
CLOUDFLARE_API_TOKEN=<your-token>
and/or
export ACME_EMAIL=<your-user>
export CLOUDFLARE_API_TOKEN=<your-token>
activate the cloud flare certificate mode
make auto-pki
make verify
api container resetet => delete faulty 0074* migration file again
docker exec -it openbalena-api-1 /bin/bash
rm src/migrations/0074-normalize-release-contract.async.ts
exit
docker restart openbalena-api-1
go to your dev-laptop and start hacking with newest open balena server
balena login -t <your_balena_token>
2 Likes