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!
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!
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.2
all 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.
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.
sudo apt-get update && sudo apt-get install -y make openssl git jq
sudo su balena
cd /home/balena
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
git restore compose/version
git pull
export DNS_TLD=<your-domain>
nano docker-compose.yml
to this by the volume definition and for the s3 and db container
db-data => db
s3-data => s3
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'
there is a faulty jq parsing command
nano Makefile
go to wait: -section and repair jq query
jq -r '.Health' => jq -r '.[ ].Health'
make up
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!
docker exec -it openbalena-api-1 /bin/bash
rm src/migrations/0074-normalize-release-contract.async.ts
exit
docker restart openbalena-api-1
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
\d+ release
ALTER TABLE release DROP CONSTRAINT "release$69zgYrVSJaN1avGiEeipPlJ9/lMKzOIt3iMPF6u/6WY=";
ALTER TABLE release DROP CONSTRAINT "release$RcddhgkY+99IgKXAUId7Q3iN4WylzgAxSFiF+JvyRiY=";
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
docker start openbalena-api-1
docker ps
docker restart openbalena-vpn-1
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
nano .env
ACME_EMAIL=<your-user>
CLOUDFLARE_API_TOKEN=<your-token>
and/or
export ACME_EMAIL=<your-user>
export CLOUDFLARE_API_TOKEN=<your-token>
make auto-pki
make verify
docker exec -it openbalena-api-1 /bin/bash
rm src/migrations/0074-normalize-release-contract.async.ts
exit
docker restart openbalena-api-1
balena login -t <your_balena_token>