Skip to content

Remove DEFAULT_FILE_STORAGE from prod.py template — deploy-blocking conflict with regluit#1202 (STORAGES) - #61

Merged
rdhyee merged 1 commit into
masterfrom
fix/prod-template-storages
Jul 22, 2026
Merged

Remove DEFAULT_FILE_STORAGE from prod.py template — deploy-blocking conflict with regluit#1202 (STORAGES)#61
rdhyee merged 1 commit into
masterfrom
fix/prod-template-storages

Conversation

@rdhyee

@rdhyee rdhyee commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Gluejar/regluit#1202 migrates file storage to the STORAGES dict in settings/common.py (required for Django 5.x). The rendered prod.py (this template, line 175) still sets DEFAULT_FILE_STORAGE after common.py loads:

  • Django 4.2 (today): setting both raises ImproperlyConfigured: DEFAULT_FILE_STORAGE/STORAGES are mutually exclusivewhole-site 500 at boot the moment #1202 deploys. (Reproduced locally, exact error.)
  • Django 5.1+ (after #1203): the line is silently ignored → S3 storage dropped.

The rendered value is identical to what common.py's STORAGES selects when AWS keys are present, so removal is behavior-neutral once #1202 lands.

Deploy coordination: merge this and deploy (--tags config render of prod.py) in the same deploy window as regluit#1202 — #1202 must not reach test or prod while the old template line is live. Found by Codex review of the Django 5.2 spike (#1203).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Fm18PoiZmSo2iJGWHuVNm4

…gluit#1202)

regluit#1202 moves file storage to the STORAGES dict in settings/common.py
(required for Django 5.x, where DEFAULT_FILE_STORAGE is removed). Django 4.2
raises ImproperlyConfigured when DEFAULT_FILE_STORAGE and an explicit STORAGES
are both set, so leaving this line in the rendered prod.py would 500 the site
at boot the moment #1202 deploys. On 5.1+ the line would instead be silently
ignored (dropping S3). Either way it must go, in the same deploy as #1202.

The rendered value was identical to what common.py's STORAGES selects when AWS
keys are present, so removal is behavior-neutral once #1202 lands.

Found by Codex review of Gluejar/regluit#1203 (Django 5.2 spike), confirmed
empirically (the exact ImproperlyConfigured was reproduced locally).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fm18PoiZmSo2iJGWHuVNm4
@rdhyee rdhyee added the CC+Codex+LGTM Authored by Claude Code and reviewed by Codex; both approved (LGTM). Awaiting human review/merge. label Jul 3, 2026
@rdhyee

rdhyee commented Jul 3, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Codex review: LGTM. No Jinja issues; no remaining active DEFAULT_FILE_STORAGE assignment anywhere in the provisioning repo. Codex's caveat (AWS keys must still reach settings/common.py) is satisfied by the existing, untouched keys/host.py render — that mechanism is unchanged. Deploy in the same window as Gluejar/regluit#1202.

@rdhyee rdhyee moved this to In Review in Unglue.it Modernization Jul 15, 2026
@rdhyee
rdhyee merged commit 4a8cc47 into master Jul 22, 2026
rdhyee added a commit that referenced this pull request Jul 22, 2026
…p-prod.yml)

Needed to render prod.py.j2 changes (e.g. #61 DEFAULT_FILE_STORAGE removal) onto
test.unglue.it via the tagged config path instead of hand-editing. group_vars/test
supplies the per-env vault values by group membership.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CZoSkYdkKLH37tH4QbEmH7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CC+Codex+LGTM Authored by Claude Code and reviewed by Codex; both approved (LGTM). Awaiting human review/merge.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant