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

Support to bulk import multiple objects #9550

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

Originally created by @dmulyalin on GitHub (Apr 27, 2024).

NetBox version

v3.7.6

Feature type

New functionality

Proposed functionality

Add support to import multiple objects into Netbox using YAML/JSON files of this structure:

dcim:
  sites:
    - <list of sites data>
  racks:
    - <list of racks data>
  devices:
    - <list of devices data>
ipam:
  prefixes:
    - <list of prefixes data>
  ip_addresses:
    - <list of IP addresses data>
<...>

Import dictionary structure follows Netbox API endpoints.

Use case

Currently to model single site need to use this list of import CSV spreadsheets (or more in some cases):

  • site_data.csv
  • rack_data.csv
  • devices_data.csv
  • modules_data.csv
  • inventory_items_data.csv
  • interfaces_data.csv
  • cables_data.csv
  • vlans_data.csv
  • bgp_asn_data.csv
  • prefixes_data.csv
  • ip_addresses_data.csv
  • circuits_data.csv

which is fine for initial import of many locations for example during brown field network onboarding into Netbox. However, modifying 10+ spreadsheets for addition of each new site is tedious especially if only few parameters changing such as site ID and IP addresses.

Being able to put a single YAML/JSON file to import all site data would simplify the process of onboarding new sites significantly. Moreover, this would allow to templatize entire portions of the network for importing into Netbox.

For example, DC-1 was imported into Netbox using YAML/JSON bulk import file, next DC-2 being built, import of entire new data center would be a mater of modifying DC-1 file to adjust few changing parameters.

Another use case could be, brown field network onboarding - organization can develop a script that will be producing bulk import data files, out of network discovery data (SNMP, device configurations, Netconf etc) allowing Engineers to review the file before import prior to uploading it into Netbox.

For many organization (from my past and current experience) it would be a game changing functionality, if they have to onboard hundreds of nearly identical sites into Netbox on frequent basis or build multiple nearly identical network segments (i.e. data centers, office campuses etc.).

Database changes

None

External dependencies

None

Originally created by @dmulyalin on GitHub (Apr 27, 2024). ### NetBox version v3.7.6 ### Feature type New functionality ### Proposed functionality Add support to import multiple objects into Netbox using YAML/JSON files of this structure: ``` dcim: sites: - <list of sites data> racks: - <list of racks data> devices: - <list of devices data> ipam: prefixes: - <list of prefixes data> ip_addresses: - <list of IP addresses data> <...> ``` Import dictionary structure follows Netbox API endpoints. ### Use case Currently to model single site need to use this list of import CSV spreadsheets (or more in some cases): - site_data.csv - rack_data.csv - devices_data.csv - modules_data.csv - inventory_items_data.csv - interfaces_data.csv - cables_data.csv - vlans_data.csv - bgp_asn_data.csv - prefixes_data.csv - ip_addresses_data.csv - circuits_data.csv which is fine for initial import of many locations for example during brown field network onboarding into Netbox. However, modifying 10+ spreadsheets for addition of each new site is tedious especially if only few parameters changing such as site ID and IP addresses. Being able to put a single YAML/JSON file to import all site data would simplify the process of onboarding new sites significantly. Moreover, this would allow to templatize entire portions of the network for importing into Netbox. For example, DC-1 was imported into Netbox using YAML/JSON bulk import file, next DC-2 being built, import of entire new data center would be a mater of modifying DC-1 file to adjust few changing parameters. Another use case could be, brown field network onboarding - organization can develop a script that will be producing bulk import data files, out of network discovery data (SNMP, device configurations, Netconf etc) allowing Engineers to review the file before import prior to uploading it into Netbox. For many organization (from my past and current experience) it would be a game changing functionality, if they have to onboard hundreds of nearly identical sites into Netbox on frequent basis or build multiple nearly identical network segments (i.e. data centers, office campuses etc.). ### Database changes None ### External dependencies None
adam added the type: feature label 2025-12-29 20:51:21 +01:00
adam closed this issue 2025-12-29 20:51:21 +01:00
adam commented 2025-12-29 20:51:21 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Apr 27, 2024):

Possible WEB UI location for this functionality could be Operations -> Integrations -> Bulk Import

@dmulyalin commented on GitHub (Apr 27, 2024): Possible WEB UI location for this functionality could be `Operations -> Integrations -> Bulk Import`
adam commented 2025-12-29 20:51:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 29, 2024):

We've considered this in the past, but there's simply too much complexity involved with importing multiple types of objects simultaneously to handle validation in a performant and user-friendly manner. For instances where you need to import many objects, we recommend either automatically consuming the REST API or writing a purpose-built custom script to ensure all operations occur in the anticipated sequence.

@jeremystretch commented on GitHub (Apr 29, 2024): We've considered this in the past, but there's simply too much complexity involved with importing multiple types of objects simultaneously to handle validation in a performant and user-friendly manner. For instances where you need to import many objects, we recommend either automatically consuming the REST API or writing a purpose-built [custom script](https://docs.netbox.dev/en/stable/customization/custom-scripts/) to ensure all operations occur in the anticipated sequence.
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 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#9550
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?