starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-14 06:13:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Use Django-storages for scripts and Replace STORAGE_BACKEND and STORAGE_CONFIG configuration parameters with Django's STORAGES #10891

New Issue
Closed
opened 2025-12-29 21:37:21 +01:00 by adam · 0 comments
adam commented 2025-12-29 21:37:21 +01:00
Owner
Copy Link

Originally created by @arthanson on GitHub (Mar 13, 2025).

Originally assigned to: @arthanson on GitHub.

NetBox version

v4.2.5

Feature type

Change to existing functionality

Proposed functionality

NetBox currently uses the local file system for saving and running scripts - this would change it to use Django-storages which would allow uploading and running scripts from S3 or other remote storages.

This would require more flexibility in configuration of STORAGES than is currently provided by the config setting STORAGE_BACKEND, so using STORAGES directly in configuration.py directly would be better. 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

There are some use cases where local file system is not available or directly accessible on the instance of NetBox (some docker configurations and cloud). This can be the case for ephemeral storage, read-only lockdown on Docker containers or stricter permission issues.

When using Kubernetes for deployment the instances can be ephemeral which means scripts are not directly copied to each node, so another layer is needed to sync the scripts (eventual consistency) which can lead to problems with the copying process not being completed by the time the script is run.

S3FS can be used in some cases to mount S3 as a local drive, but it has issues as it does not support Amazon Linux and can have permission issues.

Changing the script code to use Django-storages would fix these issues and allow scripts to be run from remote storages.

Note: 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.

The extent of these changes would be:

  • Allow settings STORAGES directly in configuration.py instead of STORAGE_BACKEND and STORAGE_CONFIG, depreciate these two settings.
  • Switch the script file upload code to use Django-storages
  • Allow the script running code (specifically the inspect python module specific code that loads modules) to use Django-storages. Note: inspect only directly supports direct file system access, so some changes will need to be made to support it using Django-storages.

Database changes

N/A

External dependencies

Django-storages

Originally created by @arthanson on GitHub (Mar 13, 2025). Originally assigned to: @arthanson on GitHub. ### NetBox version v4.2.5 ### Feature type Change to existing functionality ### Proposed functionality NetBox currently uses the local file system for saving and running scripts - this would change it to use Django-storages which would allow uploading and running scripts from S3 or other remote storages. This would require more flexibility in configuration of STORAGES than is currently provided by the config setting STORAGE_BACKEND, so using STORAGES directly in configuration.py directly would be better. 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 There are some use cases where local file system is not available or directly accessible on the instance of NetBox (some docker configurations and cloud). This can be the case for ephemeral storage, read-only lockdown on Docker containers or stricter permission issues. When using Kubernetes for deployment the instances can be ephemeral which means scripts are not directly copied to each node, so another layer is needed to sync the scripts (eventual consistency) which can lead to problems with the copying process not being completed by the time the script is run. S3FS can be used in some cases to mount S3 as a local drive, but it has issues as it does not support Amazon Linux and can have permission issues. Changing the script code to use Django-storages would fix these issues and allow scripts to be run from remote storages. **Note:** 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. The extent of these changes would be: * Allow settings STORAGES directly in configuration.py instead of STORAGE_BACKEND and STORAGE_CONFIG, depreciate these two settings. * Switch the script file upload code to use Django-storages * Allow the script running code (specifically the inspect python module specific code that loads modules) to use Django-storages. Note: inspect only directly supports direct file system access, so some changes will need to be made to support it using Django-storages. ### Database changes N/A ### External dependencies Django-storages
adam added the status: acceptedtype: featurecomplexity: medium labels 2025-12-29 21:37:21 +01:00
adam closed this issue 2025-12-29 21:37:21 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: medium status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10891
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?