Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
arthanson opened this issue Mar 13, 2025 · 0 comments
Assignees
Labels
complexity: medium Requires a substantial but not unusual amount of effort to implement status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@arthanson
Copy link
Collaborator

arthanson commented Mar 13, 2025

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

@arthanson arthanson added status: needs triage This issue is awaiting triage by a maintainer type: feature Introduction of new functionality to the application labels Mar 13, 2025
@arthanson arthanson self-assigned this Mar 13, 2025
@arthanson arthanson added status: accepted This issue has been accepted for implementation complexity: medium Requires a substantial but not unusual amount of effort to implement and removed status: needs triage This issue is awaiting triage by a maintainer labels Mar 13, 2025
@arthanson arthanson added this to the v4.3 milestone Apr 14, 2025
jnovinger added a commit that referenced this issue May 23, 2025
ScriptFileSystemStorage was introduced in #18896 and stores a full path
in Script.file_path. This fix handles looking for scripts by relative
path as well as full path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: medium Requires a substantial but not unusual amount of effort to implement status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

1 participant