Limit Platform by Device Role

[benwa]

NetBox version

v4.5.8

Feature type

Change to existing functionality

Proposed functionality

Currently, Platforms can be restricted by Manufacturer, which is great. I would also like to see it able to be restricted by Device type.

Use case

For manufacturers like Cisco, Dell, and HPE, who make networking gear and servers, it can be useful to limit the platform.
Cisco has NX-OS, but also UCS hardware that can run ESXi. I would like to be able to say

NX-OS can only be installed on devices with the "Cisco" Manufacturer that have the "Core Switch" or "Switch" Device Role.

ESXi can only be installed on devices with the "Server" Device Role, on any Manufacturer.

Database changes

No response

External dependencies

No response

[jeremystretch]

@benwa is the ask to restrict by device role, by device type, or both?

[benwa]

My thought is it should be both, either, or neither. Not necessarily Device Type but Manufacturer (as it is now), as generally, there are many models of hardware that run the same Platform.

[jeremystretch]

IMO we should dispense with all restrictions on Platform. The relationship seems to frequently confuse users.

[sleepinggenius2]

Having no restrictions would also be confusing. I already get questions from our engineers about things like why it shows IOS XE options for a device that can only run IOS XR, so I can just imagine the conversation if it starts showing EOS and Junos and everything else under the sun. With the addition of nested platforms, I would offer a suggestion for a different approach. In our environment, we have a hierarchy like Cisco IOS XR -> Cisco IOS XR 7 -> Cisco IOS XR 7.11.21 and the default platform for a router would be set to Cisco IOS XR. For something like IOS XE, we have an additional level that splits the platforms by device type, like switch, router, AP, CMTS, etc. If the system could show the entire subtree with the default platform as the root, then that would work great and limit the choices to just what's relevant to the device. If the default platform is null, then it could default to either how it works today or just showing all the options. If there is a concern about overloading the default platform field for this purpose, then an additional field could be added to point to the root platform in the tree instead. That would provide the added benefit of also being able to restrict the default platform selection to that tree as well.

That should address OP's concern regarding device type. Regarding device role, I can't think of a scenario in our environment where a given device type would have a different platform based on its role, but I think you could still leverage the tree structure to cover some role scenarios. For example, if you have server hardware you could create a platform root for "Server OS" with subtrees for Windows, Linux, whatever you need, and that could include something like Cisco Catalyst 8000V, either as a direct child or under whatever additional hierarchy you need. Then for the device type for your server you can select "Server OS" as the default platform and limit the options that way. It's not a perfect solution to every scenario, but I think it gets you to a point where you can have a reasonable list of platforms that can run on a specific device, even if it might not be restricted all the way down based on the exact role that a device which can support multiple independent platforms would expect, but I believe it does address the use cases that OP included.

Using this approach could also allow for removing the restrictions around platform and manufacturer that are in place today and address a longstanding point of confusion by finally allowing a platform for Windows to have its manufacturer set to Microsoft, ESXi to VMware/Broadcom, and so on without causing other side effects.

I would be happy to submit a separate FR for this approach, if that would be preferred.

[jeremystretch]

My thought is it should be both, either, or neither. Not necessarily Device Type but Manufacturer (as it is now), as generally, there are many models of hardware that run the same Platform.

What is the specific proposal being made in this FR?

[benwa]

Being able to restrict a Platform by Device Role.

That way we can restrict things like installing ESXi onto Cisco UCS hardware but not Cisco Catalyst switches (same Manufacturer) but different Device Role.

[sleepinggenius2]

You say device role, but your example uses device type (Cisco UCS vs Cisco Catalyst switch). Using role alone, a "Switch" role could use IOS, IOS-XE, or NX-OS for Cisco switches, or Junos for Juniper switches, EOS for Arista switches, etc. It makes more sense to me to use the device type. Using your example, you would have a device type for Cisco UCS C225 M8 with ESXi as the platform, then a Cisco Catalyst WS-C2960X-24TD-L with Cisco IOS as the platform, then a Cisco Catalyst C9300-24T with Cisco IOS-XE as the platform, etc. Limiting it to a single platform doesn't make a lot of sense though, which is why I suggested being able to point it at a tree instead.

[benwa]

I might have confused terminology. But for example, UCS can run ESXi, Windows, Linux, etc. As could HPE server hardware, which is why I said Device Role.

Importantly, I don't think it should replace existing functionality, but act as an AND/OR.

[pheus]

Thanks for opening this feature request and for the additional context from everyone who has commented.

At this point, I think the desired behavior and scope still need some clarification before this can be treated as an actionable feature request. The discussion has raised a few related but different possibilities, including restricting platforms by device role, device type, manufacturer, platform hierarchy, or some combination of these.

To avoid prematurely narrowing the scope, I'm going to convert this issue to a discussion so the community can provide feedback on the expected behavior and relevant use cases.

Once there is a clearer consensus around the problem to solve and the desired implementation approach, a new feature request can be opened with a more concrete proposal and well-defined use case.