How to set config.txt vars without fleet/device cloud configuration

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?

@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:

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/

I hope you find this useful.

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

1 Like

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.

1 Like

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.