Enable streamlined upgrades with local.py#408
Enable streamlined upgrades with local.py#408cpeel wants to merge 1 commit intosingularityhub:masterfrom cpeel:improved-local-configs
Conversation
Improve the upgrade experience by having users configure settings by making override updates to settings/local.py rather than changing settings/config.py. This improves the k8s deployment experience by only setting values we want to override rather than the entire config.py.
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: #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 #409 |
2 participants
Improve the k8s deployment experience by making override updates to
settings/local.pyrather than changing the entiresettings/config.py, like was done in the helm templates referenced in #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.pyif they want).local.pyeverything continues to work.secrets.py).local.pyvsconfig.py) requiring several doc updates.config.pyintolocal.py.Other approaches considered:
config.pyto 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.pyand have them picked up and overrideconfig.py. This hacky approach convolutes the separation of secrets vs configuration data.