I dont want to set config/env vars in the cloud fleet/device managment section as I dont want to separate my code and configuration. I thought to try to set these at the docker compose level with an ENV for instance. But haven’t found anything saying if it should work or not so I’m having my doubts.
environment:
- RESIN_HOST_CONFIG_gpu_mem=160
Should this work? Is there another way?
So you have the following options for running balenaOS;
If you use it as a standalone, then you can change the values in config.txt and they should persist.
If you use it in tandem with a balenaCloud application then the supervisor will ensure that the device configuration state matches whatever is held in the cloud. So if you change the config.txt file then the supervisor will overwrite those changes.
If you would like to keep your configuration in your code repo, then you could add a container to your compose file which has access to the API and sets the device_config_variables for the specific device it is running on. Details on accessing the API can be found here:
I hope you find this useful.
@jacobrosenthal
So you have the following options for running balenaOS;
use balenaOS standalone, without associating it to a balenaCloud application
use balenaOS in tandem with a balenaCloud application
If you use it as a standalone, then you can change the values in config.txt and they should persist.
If you use it in tandem with a balenaCloud application then the supervisor will ensure that the device configuration state matches whatever is held in the cloud. So if you change the config.txt file then the supervisor will overwrite those changes.
If you would like to keep your configuration in your code repo, then you could add a container to your compose file which has access to the API and sets the device_config_variables for the specific device it is running on. Details on accessing the API can be found here:
label to expose API key: https://www.balena.io/docs/learn/develop/multicontainer/#labels
calling the API: https://www.balena.io/docs/reference/api/overview/
config related resource: https://www.balena.io/docs/reference/api/resources/device_config_variable/
Thanks for the info. This seems like a hole? Let me explain further my use case, maybe Im using balena incorrectly.
It seems like for at least some subset of config.txt flags these are very application and hardware specific and should change with the application. If Im adding an i2c device, I need to know that i2c has been enabled or at least very strongly indicate it needs to be enabled for this application to work.
Id also like to automated deploy to the cloud presumably via a ci tag, Who and when do we remember to read the comments and swap out all the config variables in the cloud service? Never mind with 10 or 100 devices in the fleet, now Im juggling old and new configuration vars as those devices slowly update?
Im also worried about being able PRs locally on device before going to the cloud. There seems to be no way to consistently know that the vars were applied correctly without relying on humans to edit files outside of the commit which we know wont work.
Does anyones workflow solve this someway Im not thinking of?
Thanks,
Jacob
In this example Im actually using balena cloud. I just dont want to be using a gui to configure production images except where absolutely necessary.
This seems to be a pretty useful link, have you checked it out at all? It seems like you could build a tool to automatically configure the device remotely based on device id.
Generally I agree, I would be interested to know some recommended strategies for managing device configuration from the balena team.
I certainly did and I agree it looks very extensible for me to develop a method to sync vars from a file based on a github action or something and I may well do that.
I just dont feel its an ideal solution and something I think it would be nice if the platform handled for us.