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

Enable the import of device types from JSON-formatted definitions #346

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

Originally created by @jeremystretch on GitHub (Aug 10, 2016).

Currently, each NetBox user must create their own device types. This results in wasted effort because users inevitably end up duplicating work. For instance, ten users who each use Juniper EX4300-48T switches will end up creating identical (or at least exceeding similar) device types.

We don't want to pre-populate device types in NetBox on initial installation, because it's impossible to predict which device types a user will want. Extraneous device types would result in clutter that needs to be deleted.

Ideally, we could begin compiling a library of device type definitions formatted as JSON. A user could select the desired device types from the library and import them into NetBox to create device types.

Originally created by @jeremystretch on GitHub (Aug 10, 2016). Currently, each NetBox user must create their own device types. This results in wasted effort because users inevitably end up duplicating work. For instance, ten users who each use Juniper EX4300-48T switches will end up creating identical (or at least exceeding similar) device types. We don't want to pre-populate device types in NetBox on initial installation, because it's impossible to predict which device types a user will want. Extraneous device types would result in clutter that needs to be deleted. Ideally, we could begin compiling a library of device type definitions formatted as JSON. A user could select the desired device types from the library and import them into NetBox to create device types.
adam added the status: accepted label 2025-12-29 16:21:07 +01:00
adam closed this issue 2025-12-29 16:21:08 +01:00
adam commented 2025-12-29 16:21:08 +01:00
Author
Owner
Copy Link

@fltchr commented on GitHub (Aug 10, 2016):

Is this users per instance (i.e. if I create a device for a Cisco 3560, my boss won't be able to select it), or NetBox users in general (i.e. if I create a device, there is no "device community" to share it with other companies?

If the first point, I haven't noticed yet (haven't tested on more than one user account as of yet), but we'll definitely need that before moving forward., if the second, a user submitted gallery or library would be an awesome resource.

@fltchr commented on GitHub (Aug 10, 2016): Is this users per instance (i.e. if I create a device for a Cisco 3560, my boss won't be able to select it), or NetBox users in general (i.e. if I create a device, there is no "device community" to share it with other companies? If the first point, I haven't noticed yet (haven't tested on more than one user account as of yet), but we'll definitely need that before moving forward., if the second, a user submitted gallery or library would be an awesome resource.
adam commented 2025-12-29 16:21:09 +01:00
Author
Owner
Copy Link

@rgstori commented on GitHub (Aug 10, 2016):

+1 for the user submitted gallery, I think it would be very popular;
even with anybody's particular setting, little tweaks to each device type can
always be done after the import

@rgstori commented on GitHub (Aug 10, 2016): +1 for the user submitted gallery, I think it would be very popular; even with anybody's particular setting, little tweaks to each device type can always be done after the import
adam commented 2025-12-29 16:21:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 10, 2016):

@fltchr "User" in this context just means an organization using NetBox. Sorry for the confusion.

Here's a scenario. You just got in a shipment of Juniper QFX5100-48S switches that need to be racked up. You've never used these before, so first you need to create a new device type in NetBox. But rather than creating one manually, you can instruct NetBox to import a definition from a GitHub repo, e.g. netbox-devicetypes/juniper/qfx5100-48s.json. NetBox downloads the file and automatically creates a new DeviceType along with its console, power, and interface templates as defined.

I just need to come up with the logic to process JSON and start a library.

@jeremystretch commented on GitHub (Aug 10, 2016): @fltchr "User" in this context just means an organization using NetBox. Sorry for the confusion. Here's a scenario. You just got in a shipment of Juniper QFX5100-48S switches that need to be racked up. You've never used these before, so first you need to create a new device type in NetBox. But rather than creating one manually, you can instruct NetBox to import a definition from a GitHub repo, e.g. `netbox-devicetypes/juniper/qfx5100-48s.json`. NetBox downloads the file and automatically creates a new DeviceType along with its console, power, and interface templates as defined. I just need to come up with the logic to process JSON and start a library.
adam commented 2025-12-29 16:21:09 +01:00
Author
Owner
Copy Link

@stianvi commented on GitHub (Aug 11, 2016):

@jeremystretch There are also modules for devices that need to be taken into consideration.

example:
QFX5100-24Q: 32 ports (with hot-swappable expansion modules)
QFX5100-24Q-AA: 32 ports (with hot-swappable expansion modules)

And then there is the cabling too:
QFX5100-48S: 72 ports (48 10GbE SFP/SFP+ ports + 24 10GbE ports using QSFP+ to SFP+ DAC or QSFP+ to SFP+ fiber splitter cables and optics)

@stianvi commented on GitHub (Aug 11, 2016): @jeremystretch There are also modules for devices that need to be taken into consideration. example: QFX5100-24Q: 32 ports (with hot-swappable expansion modules) QFX5100-24Q-AA: 32 ports (with hot-swappable expansion modules) And then there is the cabling too: QFX5100-48S: 72 ports (48 10GbE SFP/SFP+ ports + 24 10GbE ports using QSFP+ to SFP+ DAC or QSFP+ to SFP+ fiber splitter cables and optics)
adam commented 2025-12-29 16:21:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 12, 2016):

@stianvi Expansion modules aren't part of the device, so they aren't attached to a device type. They may or may not be installed; that's up to the user to define. And cabling isn't modelled at all.

@jeremystretch commented on GitHub (Aug 12, 2016): @stianvi Expansion modules aren't part of the device, so they aren't attached to a device type. They may or may not be installed; that's up to the user to define. And cabling isn't modelled at all.
adam commented 2025-12-29 16:21:09 +01:00
Author
Owner
Copy Link

@leandroteleco commented on GitHub (Sep 4, 2016):

I'm very interested on this feature.
I'm working at important Service Provider and we are testing Netbox at our Demolab,

Thanks you for to do and to improve NetBox, I think could countribute with the device types submitted gallery. :)

@leandroteleco commented on GitHub (Sep 4, 2016): I'm very interested on this feature. I'm working at important Service Provider and we are testing Netbox at our Demolab, Thanks you for to do and to improve NetBox, I think could countribute with the device types submitted gallery. :)
adam commented 2025-12-29 16:21:10 +01:00
Author
Owner
Copy Link

@askbow commented on GitHub (Nov 11, 2016):

An export feature for device types might be a good idea too: some of us have already created libraries of devices, sharing them might be useful, given import is implemented.

@askbow commented on GitHub (Nov 11, 2016): An export feature for device types might be a good idea too: some of us have already created libraries of devices, sharing them might be useful, given import is implemented.
adam commented 2025-12-29 16:21:10 +01:00
Author
Owner
Copy Link

@tobymccann commented on GitHub (Jan 17, 2017):

This would be extremely useful, including some of the ideas already mentioned such as export. I imagine some type of verification mechanism to verify the accuracy of each device type, but that could probably be controlled via Github workflow.

@tobymccann commented on GitHub (Jan 17, 2017): This would be extremely useful, including some of the ideas already mentioned such as export. I imagine some type of verification mechanism to verify the accuracy of each device type, but that could probably be controlled via Github workflow.
adam commented 2025-12-29 16:21:10 +01:00
Author
Owner
Copy Link

@prolix21 commented on GitHub (Feb 9, 2017):

This would save so much work. We just setup Netbox and the thought of having to create all these device types gives me a headache.

@prolix21 commented on GitHub (Feb 9, 2017): This would save so much work. We just setup Netbox and the thought of having to create all these device types gives me a headache.
adam commented 2025-12-29 16:21:10 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Apr 19, 2017):

@jeremystretch I'm not sure the viability, but, Cisco/Juniper provide Visio stencils for all their hardware.

Providing one could process those VSS files (they are hexadecimal) you might be able to "easily" convert all the Visio stencils to JSON based on the data provided within.

That said, I'm not sure if the stencils include mgmt or con ports but it might be a place to start:

http://www.cisco.com/c/en/us/products/visio-stencil-listing.html
https://www.juniper.net/us/en/products-services/icons-stencils/

If it goes that easily, perhaps also do the linecards so when NAPALM runs inventory it could suggest adding templates for discovered children?

I would also recommend that users with existing devices templates be able to "upgrade" their devices to the new templates as a method of standardization - if they so chose.

@bellwood commented on GitHub (Apr 19, 2017): @jeremystretch I'm not sure the viability, but, Cisco/Juniper provide Visio stencils for all their hardware. Providing one could process those VSS files (they are hexadecimal) you might be able to "easily" convert all the Visio stencils to JSON based on the data provided within. That said, I'm not sure if the stencils include mgmt or con ports but it might be a place to start: http://www.cisco.com/c/en/us/products/visio-stencil-listing.html https://www.juniper.net/us/en/products-services/icons-stencils/ If it goes that easily, perhaps also do the linecards so when NAPALM runs inventory it could suggest adding templates for discovered children? I would also recommend that users with existing devices templates be able to "upgrade" their devices to the new templates as a method of standardization - if they so chose.
adam commented 2025-12-29 16:21:10 +01:00
Author
Owner
Copy Link

@askbow commented on GitHub (Apr 25, 2017):

@bellwood probably this can be used to convert VSS files to something more open: https://github.com/kakwa/libvisio2svg

these VSS pictures might be somewhat useful for drawing rack faces (if you want them to look fancy), but I doubt you can export ports or other sticky points.

@askbow commented on GitHub (Apr 25, 2017): @bellwood probably this can be used to convert VSS files to something more open: https://github.com/kakwa/libvisio2svg these VSS pictures might be somewhat useful for drawing rack faces (_if you want them to look fancy_), but I doubt you can export ports or other sticky points.
adam commented 2025-12-29 16:21:11 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Apr 25, 2017):

I was hoping more for port details than graphics for JSON library building,
just figured it's a somewhat complete provider library we might be able to
process it

Graphics could/would nice though on the rack elevations via another feature
request

@bellwood commented on GitHub (Apr 25, 2017): I was hoping more for port details than graphics for JSON library building, just figured it's a somewhat complete provider library we might be able to process it Graphics could/would nice though on the rack elevations via another feature request
adam commented 2025-12-29 16:21:11 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (May 2, 2019):

@jeremystretch I found this nice library: django-import-export
Maybe we could use this or the implementation logic for working with the json in / export ?
I´m not an django expert to implement this stuff but maybe this would help you ?

@tb-killa commented on GitHub (May 2, 2019): @jeremystretch I found this nice library: **django-import-export** Maybe we could use this or the implementation logic for working with the json in / export ? I´m not an django expert to implement this stuff but maybe this would help you ?
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 status: accepted
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#346
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?