Device Type Variations

[zmaster7]

I suppose this could be considered both a couple different ideas and a discussion on how others are approaching the situation of accurately modeling multiple variations of the same/similar device type. I stumbled upon the previous discussion #8404 which sort of touches upon this idea as well.

Before I get into the proposed ideas, I will provide the example of a Dell PowerEdge R6525:

As you can see, there are multiple chassis variations for the front storage, and that also has an impact on options for the rear, number of CPUs, etc. Currently in Netbox, you would have to create a separate device type for each variation to accurately reflect the chassis with the front/rear image, and for ease of use for interfaces, inventory items, etc.

With that said, I would like to propose two ideas, the first of which would be a good start and least impactful:

1. Allow us to override the front/rear image provided by the device type within a device instance (much like we are able to override the airflow currently). This would allow for a one-off chassis view that deviates from the standard model, without having to create a whole new device type. It would require more work to edit interfaces, inventory items, etc. for each device that is different, but again it is least impactful. It would also allow for depicting the addition of a NIC, disk, etc. (if someone desired to go that far).
2. Vaguely touched upon in Device Type Groups #8404, a "group" for device types could be created. This would include Manufacturer, Model, Height, Depth, Part Number (In the example used, the base model is a different part number than the chassis type used), and Parent/Child.
   Underneath that "group" would be the variations of the device type, which would include Airflow, Front/Rear Image, Device Bays, Modules, Interfaces, etc. Perhaps adding a Weight field would be helpful in determining the order in which they appear and/or a default selection.
   Alternatively, allow for nested device types, with the nested device type overriding/complimenting the parent parameters.

I understand the second proposal would have an impact on the devicetype-library, so I could see why that would be ruled out.

Thoughts?

[zmaster7]

Thinking more on the nested device types, which popped into my head as I was typing everything out, I feel would be a great addition along with option 1 without the need to override/compliment the parent parameters (since a clone of the parent can be used for the child). In my head I could visualize it working the same way as location, so it is more or less the nested view in the UI that would help the most when picking out the device type.

example:
Dell Power Edge R6525

• PE R6525: 10x SFF
  • PE R6525: 10x SFF - 2CPU

Creating each variation without the nesting visualization seems like it would be unruly.

[cslingerland]

Nested Device Types would definitely be the way to go if you ask me. Sure, the device type might be "PE R6525" but that's almost certainly not the full model number from Dell. I would assume that there's a more accurate model number for each one of those options you have for them that tells Dell exactly what it is. You would want to add each of THOSE as the device types, and then if there's functionality added in the future to group them together, then you could align the different variations that way.

[jeremystretch]

Currently in Netbox, you would have to create a separate device type for each variation to accurately reflect the chassis with the front/rear image, and for ease of use for interfaces, inventory items, etc.

Right, because these are discrete device types, each with its own unique model number and physical characteristics. It sounds like you want to introduce unnecessary complexity just to avoid creating similar device types.

[zmaster7]

I do agree that the complexity probably outweighs the benefits in terms of grouping variations (FWIW, Dell lists all of their models as one SKU, and the chassis SKU is a separate line item). I suppose I'm not as concerned about that, as I am about being able to override the the front/rear image of a device.

For example, you might have blade chassis/core switches that are populated differently from one another and want to display them as they are in the elevation view. In those examples it doesn't seem to make sense to create a different device type for each, as it's the modules/device bays that are changing, not the device itself.

Or do you think that too would add too much complexity to outweigh the benefit?