Open klutchell opened 3 years ago
[klutchell] This issue has attached support thread https://jel.ly.fish/f15cce18-c260-48e1-ae37-193b93a0f73c
You probably mean config vars (ie. not env vars) because env vars can be anything except starting with those prefixes.
We ultimately want to get rid of the prefixes -- they were (mostly) a work around to signifying special env vars before we added the "config vars" resource/concept, as both user-defined and special vars were stored as env vars. There's #34 for quite a while which is blocked for a few reasons.
Here are the ways these prefixes are significant:
RESIN_
prefix, newer use BALENA_
. We would need to be able to differentiate which one to use on the state endpoint based on the device's reported Supervisor version. The bummer is we don't necessarily know the version early enough. I think that Supervisors that accept BALENA_
prefixed config vars also accept and internally transform RESIN_
prefixed ones (we'd have to double-check as I'm not sure) which may simplify things.RESIN_
-prefixed config var and read back a BALENA_
-prefixed value may catch some clients off guard. There's no sensible way to tackle this that I can think of, except bite the bullet and hope for the best.All in all, this is totally worth raising for a brainstorm if you feel like it.
You probably mean config vars (ie. not env vars)
Yup, thank you!
I think that Supervisors that accept BALENA prefixed config vars also accept and internally transform RESIN prefixed ones (we'd have to double-check as I'm not sure) which may simplify things.
This is correct, I can confirm.
Title says it all. Not sure if replacing all hardcoded instances will have a negative effect on the current dashboard without some kind of migration?