feat: secrets.example.py #861
Conversation
Like in #577 for settings.
There was a problem hiding this comment.
A number of these settings are placed in the *.settings_local.py file rather than secrets.py.
Specifically:
ALLOWED_HOSTSCEP_AUTH_VERIFICATION_ENDPOINT
Reason: These settings do not contain sensitive credentials.
Current Example: https://github.com/TACC/Core-Portal-Deployments/blob/main/ami/camino/prod.cms.settings_local.py
Can we split these into the appropriate files (using this same setup but including the settings_local.py file as well) so the usage matches the deployment environment?
|
Thanks, yes! Will do. I am glad to have your eyes on this. |
There was a problem hiding this comment.
@taoteg I moved secret values to settings_local.py. Also, please see my question about ES_ values.
| ES_AUTH = 'username:password' | ||
| ES_HOSTS = 'http://elasticsearch:9200' | ||
| ES_INDEX_PREFIX = 'cms-dev-{}' | ||
| ES_DOMAIN = 'http://localhost:8000' | ||
|
|
||
| HAYSTACK_CONNECTIONS = { |
There was a problem hiding this comment.
@taoteg, should all of these stay in secrets.py?
- The
ES_AUTHvalue seems secret. - The
ES_…values are expected byHAYSTACK_CONNECTIONS.
There was a problem hiding this comment.
Simplifying the response - it just depends, but here is what I would do if I was truly organizing them:
ES_AUTHinsecrets.py(because sensitive)ES_INDEX_PREFIXinENV.cms.settings_local.pyES_DOMAINinENV.cms.settings_local.pyES_HOSTSincms.settings_custom.py(because shared across all hosts)
That gets a bit messy though, so keeping them all together in secrets is just easier.
Also, moving them might break the HAYSTACK_ config block due to loading order IIRC?
There was a problem hiding this comment.
Moving ES_… values would break ES if HAYSTACK… is in any of those files.
I've experienced such a load order problem before. I solved it via new section in settings.py after settings/secrets import.
I think the complexity of ES_ in many files is "not worth it". I feel safe to do so, but I defer to you.1
Footnotes
-
Would you feel compelled to update such files on servers or in Core-Portal-Deployments? ↩
There was a problem hiding this comment.
I 100% agree that it is "not worth it" due to the second-order effects.
Would you feel compelled to update such files on servers or in Core-Portal-Deployments?
I don't think any ES_ values live anywhere except in the secrets.py files, so you have to update the file on the individual host (and add any changes to the Stache entry, naturally).
There was a problem hiding this comment.
K. So, good to go this PR?
Overview
Create a
secrets.example.py.Related
settings_secret.example.pyChanges
secrets.example.pysecrets.pysettings_custom.pyTesting & UI
N/A