Support for device environment variables

This is really weird. Can you please follow the steps below to get a fresh installation up?

Pull the latest version of all services, with:

$ cd open-balena
$ ./scripts/compose pull

Then reset the current deployment (note the following will delete all data, including the database):

$ ./scripts/compose kill
$ ./scripts/compose down
$ docker volume rm openbalena_s3 openbalena_redis openbalena_db openbalena_registry

Pull the latest open-balena:

$ cd open-balena
$ git pull

Run the quickstart again:

$ ./scripts/quickstart

@WillFG I managed to reproduce the database error :slight_smile: I’m now looking to fix this.

@dfunckt - great! I thought I was doing something stupid and / or going mad…

1 Like

@WillFG just a quick note that we’re actively working on a fix for this – turns out it’s not trivial to resolve. We’ll keep you updated.

Thanks, will be very helpful when working as it’s a very useful feature.

Thanks @WillFG for posting this thread and @dfunckt for working on a fix. I’m just getting started with an openbalena self-hosted server and ran into the same database error when attempting to set env vars. @dfunckt is there a Github issue that we can follow for the fix? Or perhaps there is a workaround that you identified? Thanks.

1 Like

@dfunckt any ETA on a fix for this? If you think it is likely to be more than a couple of months I just need to come up with a workaround. Thanks for all the help.

Hey @WillFG, apologies for the delay – while it might seem that we only need to change the code to refer to the field appropriately, that would break config vars on balenaCloud (balenaCloud is now built on top of openBalena). So we’re working on refactoring a few things and moving them to open-balena which will properly fix the issue and also allow us to do other cool things such as being able to transparently introduce new API versions while maintaining compatibility with older ones. It’s a bunch of work but we’re getting there.

I though I posted this before but it seems I haven’t. You can workaround the issue by doing HTTP requests directly to the API, like so:

# creates a new application config variable
# similar request works for `device_config_variable` as well
curl -X POST 'https://api.myopenbalena.com/v5/application_config_variable' \
	-H 'authorization: Bearer <TOKEN>' \
	-H 'content-type: application/json' \
	--data-binary '{"application": <APPID>,"name":"<KEY>","value":"<VALUE>"}'

# creates a new application environment variable
# similar request works for `device_environment_variable` as well
curl -X POST 'https://api.myopenbalena.com/v5/application_environment_variable' \
	-H 'authorization: Bearer <TOKEN>' \
	-H 'content-type: application/json' \
	--data-binary '{"application": <APPID>,"env_var_name":"<KEY>","value":"<VALUE>"}'

# updates the value of an application config variable.
# similar request works for `device_config_variable` as well
curl -X PATCH 'https://api.myopenbalena.com/v5/application_config_variable(<ID>)' \
	-H 'authorization: Bearer <TOKEN>' \
	-H 'content-type: application/json' \
	--data-binary '{"value":"<VALUE>"}'

# updates the value of an application environment variable
# similar request works for `device_environment_variable` as well
curl -X PATCH 'https://api.myopenbalena.com/v5/application_environment_variable(<ID>)' \
	-H 'authorization: Bearer <TOKEN>' \
	-H 'content-type: application/json' \
	--data-binary '{"value":"<VALUE>"}'

You’ll need to adjust accordingly if you’re using self-signed certificates, as it happens by default – passing --cacert <PATH_TO_CERT> should do it for curl.

Note that these queries will stop working as soon as the issue is fixed.

@dfunckt is there a way to get the current vars?
When trying to create a new config var I get back:
"\"application\" and \"name\" must be unique.

Would be nice to know what’s already there.
Thanks.

This will fetch all application config vars across all applications:

curl 'https://api.myopenbalena.com/v5/application_config_variable' \
	-H 'authorization: Bearer <TOKEN>'

This will filter by application (works similarly for device):

curl 'https://api.myopenbalena.com/v5/application_config_variable?$filter=application%20eq%20<APPID>' \
	-H 'authorization: Bearer <TOKEN>'
1 Like

Great, I will give it a go. Does it also work for device environment variables?

@dfunckt fetching vars worked great.
Now I know my config vars are set.

But when I fetch device vars with:
curl 'https://api.url.com/v5/device_config_variable' \ -H 'authorization: Bearer <token>'

My device is only showing the following vars:
RESIN_HOST_CONFIG_disable_splash
RESIN_HOST_CONFIG_avoid_warnings

I also need a few others like
RESIN_HOST_CONFIG_gpu_mem_256

Any reason why that env var wouldn’t make it to a Raspberry Pi 3 with 2.29.2+rev1?
Or am I misunderstanding something - quite possible :slight_smile:

Update: Looks like I was confused. The env vars are being updated as soon as the devices gets registered.

Hello! No luck with everything =(
Getting : Database error

AXIOS:
axios.defaults.headers.common[‘Authorization’] = 'Bearer ’ + token;
axios({
method: ‘post’,
url: ‘https://api.balena.myhost.ua/v5/device_environment_variable’,
responseType: ‘json’,
data: {
device: ‘626983a’,
name: ‘CURRENCY_SHOW’,
value: ‘true’,
}
})
.then(function (response) {
console.log(response.data);
}).catch(function (error) {
console.log(error);
});

AND CMD:
balena env add DEVVVS true --device 626983a

The device should the numeric ID of the device, and not the UUID. If you do a GET on /v5/device then you will see the id field value :ok_hand:

Thank you! Will try =)

Still same:

Hmm. OK. I would try 2 things;

  • take the ID out of quotes, as it should be an integer
  • confirm that a device environment variable with the same name, for that device, doesn’t exist; if it does then you should be using a PATCH method, not POST.

Having tried again with the latest openBalena using the Python SDK it now appears to set device environment variables successfully.

1 Like

Glad to hear, thanks for the feedback!

@WillFG environment variables were always supported – it’s only config variables that weren’t (and actually still aren’t) via the CLI – i.e. those prefixed with RESIN_ or BALENA_.