Replace STORAGE_BACKEND and STORAGE_CONFIG configuration parameters with Django's STORAGES #10666

New Issue

adam · 2025-12-29T21:34:28+01:00

adam commented

2025-12-29 21:34:28 +01:00

Originally created by @jeremystretch on GitHub (Jan 17, 2025).

Originally assigned to: @arthanson on GitHub.

NetBox version

v4.2.1

Feature type

Change to existing functionality

Triage priority

N/A

Proposed functionality

NetBox currently exposes two configuration parameters for configuring file storage:

STORAGE_BACKEND - Sets the storage backend (e.g. django-storages)
STORAGE_CONFIG - A dictionary of backend-specific configuration parameters

We can replace these by instead exposing Django's STORAGES setting directly.

Use case

Django's native STORAGE_BACKEND setting was removed in v5.1 and superseded by STORAGES. There is no longer a need to handle the backend selection and configuration via separate configuration parameters.

Database changes

N/A

External dependencies

None

Originally created by @jeremystretch on GitHub (Jan 17, 2025). Originally assigned to: @arthanson on GitHub. ### NetBox version v4.2.1 ### Feature type Change to existing functionality ### Triage priority N/A ### Proposed functionality NetBox currently exposes two configuration parameters for configuring file storage: * `STORAGE_BACKEND` - Sets the storage backend (e.g. `django-storages`) * `STORAGE_CONFIG` - A dictionary of backend-specific configuration parameters We can replace these by instead exposing Django's [`STORAGES`](https://docs.djangoproject.com/en/5.1/ref/settings/#storages) setting directly. ### Use case Django's native `STORAGE_BACKEND` setting was [removed in v5.1](https://docs.djangoproject.com/en/5.1/releases/5.1/#features-removed-in-5-1) and superseded by `STORAGES`. There is no longer a need to handle the backend selection and configuration via separate configuration parameters. ### Database changes N/A ### External dependencies None

adam added the status: accepted type: feature complexity: low labels 2025-12-29 21:34:28 +01:00

adam closed this issue

2025-12-29 21:34:29 +01:00

adam commented

2025-12-29 21:34:29 +01:00

@RangerRick commented on GitHub (Feb 26, 2025):

I've got the NBE build set up such that I can now test this on our end, and as I worked to reenable S3 storage on my side, I remembered that one of the blockers last time around was the behavior of the storages and what gets persisted to the database.

The short version is: the entire S3 URL is stored to the database, which when inside a cluster is not reachable from the outside. Setting AWS_S3_CUSTOM_DOMAIN is not always feasible, because it would require introspection of the ingress to know what the external hostname is, and doing that reliably is problematic.

In my previous S3 PoC, I wrote a façade storage driver that stored everything relative, but then realized I didn't have enough control over how the image URLs are used elsewhere in the system so they would still not render right if, say, you have NetBox behind a proxy using a prefix, so I was still forced to hardcode the ingress hostname to make it all work.

It feels like handling this well is more complicated than just dealing with prefixes; the current S3 storage behavior assumes your S3 host never changes.

@RangerRick commented on GitHub (Feb 26, 2025): I've got the NBE build set up such that I can now test this on our end, and as I worked to reenable S3 storage on my side, I remembered that one of the blockers last time around was the behavior of the storages and what gets persisted to the database. The short version is: the entire S3 URL is stored to the database, which when inside a cluster is not reachable from the outside. Setting `AWS_S3_CUSTOM_DOMAIN` is not always feasible, because it would require introspection of the ingress to know what the external hostname is, and doing that reliably is problematic. In my previous S3 PoC, I wrote a façade storage driver that stored everything relative, but then realized I didn't have enough control over how the image URLs are used elsewhere in the system so they would still not render right if, say, you have NetBox behind a proxy using a prefix, so I was still forced to hardcode the ingress hostname to make it all work. It feels like handling this well is more complicated than just dealing with prefixes; the current S3 storage behavior assumes your S3 host never changes.

adam commented

2025-12-29 21:34:30 +01:00

@jeremystretch commented on GitHub (Mar 13, 2025):

Superseded by #18896

@jeremystretch commented on GitHub (Mar 13, 2025): Superseded by #18896

adam referenced this issue

2025-12-29 23:20:10 +01:00

[PR #10673] [MERGED] Fix LDAP auth: user never updated if inactive #13669

adam referenced this issue

2025-12-29 23:20:19 +01:00

[PR #10810] [MERGED] Release v3.3.7 #13698

adam referenced this issue