Closed cpeel closed 1 year ago
We could move to a config file or env-based approach. The challenge would be lots of changes to config.py to optionally read every variable from the file or env before falling back to a default/initial value. This approach is also challenging for representing non-string / non-numeric configuration settings (booleans, lists).
I think I actually really like this approach? I made the original sregistry a long time ago, but since then I've made (by default) most of my Django apps read everything in from either a config file or the environment. E.g., here is an example that allows loading in from a config.yaml or the environment:
And then the defaults could be set in multiple ways, e.g., here is an example (for a Django plugin) that has a defaults structure and then can override it (in our case it would be from a settings file or environment):
What do you think?
hey @cpeel ! Here is an idea to throw into the mix for envars: https://github.com/singularityhub/sregistry/pull/409. Its a bit different than what I've done before (I wanted more control over types) but I think it could be a good start? If you want to test out the branch (I won't get to before the work day starts) we can iteratively work on it (if you think it is a good direction).
Closing in lieu of https://github.com/singularityhub/sregistry/pull/409
Improve the k8s deployment experience by making override updates to
settings/local.py
rather than changing the entiresettings/config.py
, like was done in the helm templates referenced in https://github.com/singularityhub/sregistry/issues/317. A single container can now be built for use in dev/stg/prd environments and use an updated helm manifest to override values that differ in each env. This also improves the dev & upgrade experience by having local settings not pollute code under source control.Pros/cons of this approach:
config.py
if they want).local.py
everything continues to work.secrets.py
).local.py
vsconfig.py
) requiring several doc updates.config.py
intolocal.py
.Other approaches considered:
config.py
to optionally read every variable from the file or env before falling back to a default/initial value. This approach is also challenging for representing non-string / non-numeric configuration settings (booleans, lists).secret.py
and have them picked up and overrideconfig.py
. This hacky approach convolutes the separation of secrets vs configuration data.