Rewrite our settings system
Pain points:
- Misconfiguration by operators can cause the app to crash due to missing defaults
- Defining defaults manually duplicates code across the code base
- `openstack_
We need a system that is organised logically, deprecates cleanly, and is flexible enough to support the requests of packagers and deployers. At the moment, we use a base 'settings.py' file that imports overrides from a 'local_settings.py' file and `local_settings.d` directory.
Suggestion:
- Move any defaults in `settings.py` to `defaults.py`. All defaults in the code import from this file. This prevents duplication across the code base if we change a default value and ensures a default is always available regardless of operator misconfiguration or upgrade changes.
- Update docs to encourage usage of `local_settings.d` instead of `local_
End result:
- settings.py will only carry the local_settings imports and potentially some small pieces of logic to be cleaned up later on.
- customisations are added as small modular pieces in local_settings.d, rather than 1000 line local_settings files.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Rob Cresswell
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Rob Cresswell
Related branches
Related bugs
Sprints
Whiteboard
[mrunge, 16-02-2016]
I would use oslo.config rather than stevedore, and I would try to keep .py files for *config* purposes as minimal as possible.
I like the idea to have something like defaults defined, but that can be kept in .ini files directly.
[r1chardj0n3s 2016-10-25]
Perhaps we could put a few .example files into local_settings.d (instead of local_settings.
[robcresswell 2016-10-26]
That makes sense, good idea
[robcresswell 2016-10-27]
From summit:
- We need to remove logic in settings.py and move to simple data structures like dicts and lists
- https:/
