Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow For Custom Override Of Docker Compose Configuration Files #124

Closed
AKHwyJunkie opened this issue Mar 16, 2024 · 1 comment
Closed

Comments

@AKHwyJunkie
Copy link

This is an issue to track requests to allow for control over various configurations of the actual docker compose files.

Currently, there is no way to modify the actual docker compose files from within the UI, limiting the accessibility of many configuration options that are available to the various containers. (Such as graph lightmode/darkmode, Airspy CPU targets, etc.)

While you can technically overwrite the configuration files manually, any changes will be automatically overwritten by the system upon an upgrade and possibly other scenarios. (And would also be unsupportable.) It does seem to be a fairly regular request to access one or more of these features, though. (e.g. I've been on the Discord about a week and have seen it three times so far.)

Itemizing all the possible choices into a UI is likely going to result in UI clutter, complex integration and ongoing upkeep.

What I would propose is a more simple approach. It would use a multi-line text box, which then uses a regex replace to identify existing docker compose environment entries in the container's yml files and replace the desired output with the user's value. If there's no match, reject the entire thing and make the user figure out what they did wrong.

Example Text Box Entry:
AIRSPY_ADSB_CPUTIME_TARGET=95
GRAPHS1090_DARKMODE=false

Final Config In airspy.yml:
AIRSPY_ADSB_CPUTIME_TARGET=95

Final Config in docker-compose.yml:
GRAPHS1090_DARKMODE=false

Possible issues I could foresee that might require "some level" of moderation?

  • Inadvertently overriding UI controlled variables, aka magicsauce
  • Ensuring the right variables get applied to the right container environment
  • I don't think there's duplication of environment variables, but maybe?
  • Clearly a user could severely brick things by doing something like "BEASTHOST=notafeeder"
  • Options that aren't prepopulated in the project's docker compose files for some reason

Honestly, I think a simple "don't touch unless you know what you're doing" warning is sufficient. Similar to what you have with the ultrafeeder arguments. Most people just want to adjust a thing or two. Also, most people aren't stupid enough to mess with "Warning, Expert, no really, EXPERT" settings. And if they are, it should be somewhat painful.

That's just my thoughts on how to more easily implement such a feature without turning it into a UI mess.

I know I and several others would love to see it!

@AKHwyJunkie
Copy link
Author

For anyone that might be following this feature request, the functionality was added in v1.30 beta 2 (to adjust ultrafeeder) and further enhanced (to adjust all containers) in subsequent betas.

We can now add things into the newly added box "Add environment variables to containers" on the expert page to affect the container build's process. An example of how you can use this? Adding:

AIRSPY_ADSB_CPUTIME_TARGET=95

Will adjust the Airspy's ability to use more CPU, more than the default 60.

There's a few other things that are generally helpful via this functionality, like changing the graphs from the default dark mode to light mode. Technically, you can adjust practically any environmental variable for the containers. It'll be interesting to see what options come up where this is even more useful.

@dirkhh dirkhh closed this as completed Mar 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants