How to model DeviceType objects

[raddessi]

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

[hSaria]

This is something best suited for the mailing list.

[raddessi]

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]

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

[DanSheps]

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.

[raddessi]

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

[DanSheps]

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.

[raddessi]

Shall I reopen as a bugfix then?

[DanSheps]

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

[raddessi]

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.

[hSaria]

@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.

[raddessi]

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.

[jeremystretch]

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