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

How to model DeviceType objects #3376

New Issue
Closed
opened 2025-12-29 18:28:31 +01:00 by adam · 12 comments
adam commented 2025-12-29 18:28:31 +01:00
Owner
Copy Link

Originally created by @raddessi on GitHub (Feb 21, 2020).

Environment

  • Python version: 3.6.9
  • NetBox version: 2.7.3

Proposed Functionality

This is perhaps more of a question than a proposal at this point. We have ran in to the same issue that was brought up in https://github.com/netbox-community/netbox/issues/1119 where it seems the place that makes the most sense to have a piece of information is limited to a field smaller than what we can easily fit it in. I would like your thoughts on given what we are trying to accomplish, what the best way of doing it would be given how netbox is built and how it is meant to be used.

Our problem is that we have many physical models of servers (not network gear) and the parts that differentiate those models in netbox (interfaces only at this point, not even cpu or mem) are too complex to fit in 50 characters in the name field as-is. For instance we already have 81 different models of Dell devices, almost all of which are servers with different network configurations. The way I understand netbox we should have a different template only for models that have different interface configurations so that is what we have today. Here are some DeviceType names that we have:

PowerEdge R440 (2x1GbE onboard and 2x10GbE addon)
PowerEdge R440 (2x1GbE onboard and 2x1GbE addon)
PowerEdge R440 (2x1GbE onboard)
PowerEdge R440 (4x1GbE onboard and 2x10GbE addon)

And these work great! We can tell what the embedded capability and the addon card capability are as well as the speed and form factor since that is what matters most to us. But then we get in to the more comples server types and 50 characters is just not quite enough space to fit this info in, for example:

PowerEdge R620 (4x1GbE on/2x1GbE, 2x10GbSFP addon)
PowerEdge R640 (2x10GbSFP,2x1GbE,2x100GbQSPF28add)

OK, all we had to do on the first one was shorten onboard to on.. maybe that's fine, we can document that and people will understand. But as setups get more and more complex like that second example we are reaaaally struggling to fit an id that makes any human readable sense in to the field. And that second entry is ambigious about what is addon vs what is onboard. Usually in netbox there is a clear way something should be done (I love it by the way, thank you again it's an amazing project), but this is a place I'm not sure this 50 character limit is helping. That, or maybe I'm missing something I could be doing differently.

The only things I can think of are:

  1. Change the device names to an internal identifier like PowerEdge R640 Type 1, PowerEdge R640 Type 2, etc
    • This then requires we track the count/formfactor/addon-or-onboard status of interfaces in these models outside netbox and map the internal identifier back to the device type model in netbox.. which seems dirty to me.
  2. I propose a change to netbox so that the above information can be tracked in the DeviceType natively but outside the current field
    • I'm not sure what this would look like yet, I haven't spent enough time thinking about it. Maybe we need a sub device type object? We have easily tens of configurations of say PowerEdge R640 systems alone not to mention the other model families.
  3. We increase the DeviceType field
    • This lets us track what I currently assume netbox wants us to be tracking in this field, where I think netbox currently wants us to track it.. unless I'm not putting the correct type of information in the name?

If you could give me some insight in to how netbox wants devicetype models set up this would be great to know, thanks!

Use Case

Talked about above

Database Changes

I'm not sure yet.. needs discussion

External Dependencies

None

Originally created by @raddessi on GitHub (Feb 21, 2020). ### Environment * Python version: 3.6.9 * NetBox version: 2.7.3 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality This is perhaps more of a question than a proposal at this point. We have ran in to the same issue that was brought up in https://github.com/netbox-community/netbox/issues/1119 where it seems the place that makes the most sense to have a piece of information is limited to a field smaller than what we can easily fit it in. I would like your thoughts on given what we are trying to accomplish, what the best way of doing it would be given how netbox is built and how it is meant to be used. Our problem is that we have many physical models of servers (not network gear) and the parts that differentiate those models in netbox (interfaces only at this point, not even cpu or mem) are too complex to fit in 50 characters in the name field as-is. For instance we already have 81 different models of Dell devices, almost all of which are servers with different network configurations. The way I understand netbox we should have a different template only for models that have different interface configurations so that is what we have today. Here are some DeviceType names that we have: ``` PowerEdge R440 (2x1GbE onboard and 2x10GbE addon) PowerEdge R440 (2x1GbE onboard and 2x1GbE addon) PowerEdge R440 (2x1GbE onboard) PowerEdge R440 (4x1GbE onboard and 2x10GbE addon) ``` And these work great! We can tell what the embedded capability and the addon card capability are as well as the speed and form factor since that is what matters most to us. But then we get in to the more comples server types and 50 characters is just not quite enough space to fit this info in, for example: ``` PowerEdge R620 (4x1GbE on/2x1GbE, 2x10GbSFP addon) PowerEdge R640 (2x10GbSFP,2x1GbE,2x100GbQSPF28add) ``` OK, all we had to do on the first one was shorten onboard to on.. maybe that's fine, we can document that and people will understand. But as setups get more and more complex like that second example we are reaaaally struggling to fit an id that makes any human readable sense in to the field. And that second entry is ambigious about what is addon vs what is onboard. Usually in netbox there is a clear way something should be done (I love it by the way, thank you again it's an amazing project), but this is a place I'm not sure this 50 character limit is helping. That, or maybe I'm missing something I could be doing differently. The only things I can think of are: 1. Change the device names to an internal identifier like `PowerEdge R640 Type 1`, `PowerEdge R640 Type 2`, etc - This then requires we track the count/formfactor/addon-or-onboard status of interfaces in these models outside netbox and map the internal identifier back to the device type model in netbox.. which seems dirty to me. 2. I propose a change to netbox so that the above information can be tracked in the DeviceType natively but outside the current field - I'm not sure what this would look like yet, I haven't spent enough time thinking about it. Maybe we need a sub device type object? We have easily tens of configurations of say PowerEdge R640 systems alone not to mention the other model families. 3. We increase the DeviceType field - This lets us track what I currently assume netbox _wants_ us to be tracking in this field, _where_ I think netbox currently wants us to track it.. unless I'm not putting the correct type of information in the name? If you could give me some insight in to how netbox wants devicetype models set up this would be great to know, thanks! <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case Talked about above <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes I'm not sure yet.. needs discussion <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None
adam closed this issue 2025-12-29 18:28:31 +01:00
adam commented 2025-12-29 18:28:31 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 22, 2020):

This is something best suited for the mailing list.

@hSaria commented on GitHub (Feb 22, 2020): This is something best suited for the [mailing list](https://groups.google.com/forum/#!forum/netbox-discuss).
adam commented 2025-12-29 18:28:32 +01:00
Author
Owner
Copy Link

@raddessi commented on GitHub (Feb 22, 2020):

And just to clarify, the issue here is only present for servers as far as I can see, due to the very configurable nature of having multiple PCIe slots to put combinations of network cards in. Actual network gear is mostly fixed, and what isn't fixed Netbox has the Parent/Child relationship for already which works great.

@raddessi commented on GitHub (Feb 22, 2020): And just to clarify, the issue here is only present for servers as far as I can see, due to the very configurable nature of having multiple PCIe slots to put combinations of network cards in. Actual network gear is mostly fixed, and what isn't fixed Netbox has the Parent/Child relationship for already which works great.
adam commented 2025-12-29 18:28:33 +01:00
Author
Owner
Copy Link

@raddessi commented on GitHub (Feb 22, 2020):

@hSaria Why is that? I want info from the developers and designers specifically on this issue.

@raddessi commented on GitHub (Feb 22, 2020): @hSaria Why is that? I want info from the developers and designers specifically on this issue.
adam commented 2025-12-29 18:28:33 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 22, 2020):

Thank you for your interest in NetBox. GitHub issues are intended for reporting reproducible bugs and requesting features, and must be submitted using one of the templates provided here. For general discussion, questions, or assistance with installation issues, please post to our mailing list instead.

@DanSheps commented on GitHub (Feb 22, 2020): Thank you for your interest in NetBox. GitHub issues are intended for reporting reproducible bugs and requesting features, and must be submitted using one of the templates provided [here](https://github.com/digitalocean/netbox/issues/new/choose). For general discussion, questions, or assistance with installation issues, please post to our [mailing list](https://groups.google.com/forum/#!forum/netbox-discuss) instead.
adam commented 2025-12-29 18:28:33 +01:00
Author
Owner
Copy Link

@raddessi commented on GitHub (Feb 22, 2020):

I am officially requesting a feature, using your specified template.

@raddessi commented on GitHub (Feb 22, 2020): I am officially requesting a feature, using your specified template.
adam commented 2025-12-29 18:28:34 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 22, 2020):

This is not a feature request, by your own admission.

However, to answer on the basis of a feature request, we have a backlog of over 100 feature requests and enhancements. This is not something we can spend development time on at this time.

@DanSheps commented on GitHub (Feb 22, 2020): This is not a feature request, by your own admission. However, to answer on the basis of a feature request, we have a backlog of over 100 feature requests and enhancements. This is not something we can spend development time on at this time.
adam commented 2025-12-29 18:28:34 +01:00
Author
Owner
Copy Link

@raddessi commented on GitHub (Feb 22, 2020):

Shall I reopen as a bugfix then?

@raddessi commented on GitHub (Feb 22, 2020): Shall I reopen as a bugfix then?
adam commented 2025-12-29 18:28:34 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 22, 2020):

If you simply want the field increase, you could re-open as an enhancement for that specific issue only and we would take it under advisement

@DanSheps commented on GitHub (Feb 22, 2020): If you simply want the field increase, you could re-open as an enhancement for that specific issue only and we would take it under advisement
adam commented 2025-12-29 18:28:34 +01:00
Author
Owner
Copy Link

@raddessi commented on GitHub (Feb 22, 2020):

Can you not change the issue type? I chose FR as it seemed to me at the time the most fitting among the choices given. If you can not change the type, then yes I will copy and paste to a new issue.

@raddessi commented on GitHub (Feb 22, 2020): Can you not change the issue type? I chose FR as it seemed to me at the time the most fitting among the choices given. If you can not change the type, then yes I will copy and paste to a new issue.
adam commented 2025-12-29 18:28:34 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 22, 2020):

@raddessi the mailing list has a lot of lovely and helpful people that are willing to describe how they model their different device types. Asking there would get you a lot of feedback from different people. I highly recommend posting there. The issues here are used for development, which this doesn't look like.

@hSaria commented on GitHub (Feb 22, 2020): @raddessi the mailing list has a lot of lovely and helpful people that are willing to describe how they model their different device types. Asking there would get you a lot of feedback from different people. I highly recommend posting there. The issues here are used for development, which this doesn't look like.
adam commented 2025-12-29 18:28:35 +01:00
Author
Owner
Copy Link

@raddessi commented on GitHub (Feb 22, 2020):

I'm not asking how other people model their devices, I want to know, specifically from the developers, how they want it done in in this very specific case since the issue I mentioned above was closed by Jeremy. It has been said this should not be done, and I would like clarification of then how it should be done by the people who wrote the system.

@raddessi commented on GitHub (Feb 22, 2020): I'm not asking how other people model their devices, I want to know, specifically from the developers, how they _want_ it done in in this very specific case since the issue I mentioned above was closed by Jeremy. It has been said this should not be done, and I would like clarification of then how it _should_ be done by the people who wrote the system.
adam commented 2025-12-29 18:28:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 22, 2020):

And as directed by two other people already, the place to ask that is on the mailing list.

@jeremystretch commented on GitHub (Feb 22, 2020): And as directed by two other people already, the place to ask that is on the mailing list.
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
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#3376
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?