Remove Manufacturer constraint on Platform to Device assignment #10850

New Issue

adam · 2025-12-29T21:36:41+01:00

adam commented

2025-12-29 21:36:41 +01:00

Originally created by @empusas on GitHub (Mar 5, 2025).

NetBox version

v4.2

Feature type

Change to existing functionality

Proposed functionality

Currently, NetBox imposes a constraint that a Platform can only be assigned to a Device if the Manufacturer matches or if no Manufacturer is set on the Platform.

While this restriction may be reasonable for most network devices (about 95% of cases), it proves impractical for nearly everything else.

The only apparent purpose of this limitation seems to be restricting options in the UI.

Use case

As mentioned above, for about 95% of network devices, there may be a 1:1 relationship between the hardware manufacturer and the software provider.

However, in the compute world, this is not the case. Your server hardware might be from Dell or Lenovo, while the operating system could be provided by Red Hat or Microsoft.

Currently, the only workaround is to remove the Manufacturer from the Platform, which technically works but also removes valuable information that could be useful in other scenarios.

And to the argument that “NetBox is primarily for networking, not compute or storage,” I would counter:
How can you achieve a comprehensive view of infrastructure if NetBox only includes network data for cabling and IPAM, but lacks visibility into compute and storage?

Database changes

No response

External dependencies

No response

Originally created by @empusas on GitHub (Mar 5, 2025). ### NetBox version v4.2 ### Feature type Change to existing functionality ### Proposed functionality Currently, NetBox imposes a constraint that a Platform can only be assigned to a Device if the Manufacturer matches or if no Manufacturer is set on the Platform. While this restriction may be reasonable for most network devices (about 95% of cases), it proves impractical for nearly everything else. The only apparent purpose of this limitation seems to be restricting options in the UI. ### Use case As mentioned above, for about 95% of network devices, there may be a 1:1 relationship between the hardware manufacturer and the software provider. However, in the compute world, this is not the case. Your server hardware might be from Dell or Lenovo, while the operating system could be provided by Red Hat or Microsoft. Currently, the only workaround is to remove the Manufacturer from the Platform, which technically works but also removes valuable information that could be useful in other scenarios. And to the argument that “NetBox is primarily for networking, not compute or storage,” I would counter: How can you achieve a comprehensive view of infrastructure if NetBox only includes network data for cabling and IPAM, but lacks visibility into compute and storage? ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature label 2025-12-29 21:36:41 +01:00

adam closed this issue

2025-12-29 21:36:41 +01:00

adam commented

2025-12-29 21:36:42 +01:00

@Andres1357 commented on GitHub (Mar 5, 2025):

I had assumed this limitation was only present for the default manufacturer field for device types but you're right, it is actually there for the platform field on devices, as well.

Maybe a workaround is to set no manufacturer on the platforms Windows, Linux, etc. Or maybe that's the intended method.

@Andres1357 commented on GitHub (Mar 5, 2025): I had assumed this limitation was only present for the default manufacturer field for device types but you're right, it is actually there for the platform field on devices, as well. Maybe a workaround is to set no manufacturer on the platforms Windows, Linux, etc. Or maybe that's the intended method.

adam commented

2025-12-29 21:36:42 +01:00

@empusas commented on GitHub (Mar 5, 2025):

Maybe a workaround is to set no manufacturer on the platforms Windows, Linux, etc. Or maybe that's the intended method.

As I mentioned, removing the Manufacturer from the Platform is currently the only workaround. However, I believe that removing data to work around a constraint that offers little to no real advantage is not the right solution.

That said, if someone can explain why this constraint is so beneficial that it outweighs the value of having accurate and complete data in the system, I’d be happy to understand the reasoning.

@empusas commented on GitHub (Mar 5, 2025): > Maybe a workaround is to set no manufacturer on the platforms Windows, Linux, etc. Or maybe that's the intended method. As I mentioned, removing the Manufacturer from the Platform is currently the only workaround. However, I believe that removing data to work around a constraint that offers little to no real advantage is not the right solution. That said, if someone can explain why this constraint is so beneficial that it outweighs the value of having accurate and complete data in the system, I’d be happy to understand the reasoning.

adam commented

2025-12-29 21:36:42 +01:00

@ITJamie commented on GitHub (Mar 5, 2025):

adding a boolean option platform model "only allow this platform on matching device manufacturer" would be more useful in the long term and update checks to verify against that field on platform assignment.

Weve seen similar for palo and cisco virtual appliances.

@ITJamie commented on GitHub (Mar 5, 2025): adding a boolean option platform model "only allow this platform on matching device manufacturer" would be more useful in the long term and update checks to verify against that field on platform assignment. Weve seen similar for palo and cisco virtual appliances.

adam commented

2025-12-29 21:36:42 +01:00

@empusas commented on GitHub (Mar 6, 2025):

That would probably be a better solution to the problem, but it would require significantly more effort to modify the code accordingly.

Once again, I ask: What benefit does this restriction provide that would justify such effort?

@empusas commented on GitHub (Mar 6, 2025): That would probably be a better solution to the problem, but it would require significantly more effort to modify the code accordingly. Once again, I ask: What benefit does this restriction provide that would justify such effort?

adam commented

2025-12-29 21:36:43 +01:00

@sleepinggenius2 commented on GitHub (Mar 6, 2025):

Your examples are for servers. As a service provider, we only have network equipment to document in our NetBox instance and all Platforms have a Manufacturer that matches the device Manufacturer. So, with all the different equipment vendors we use, having a couple values in the dropdown versus 60+ different values that you have to remember what the particular vendor's OS is called is a huge time savings and helps maintain data integrity. As we also tie platforms to integrations/automations, selecting the correct value is critical. I can tell you from experience that when this was broken back when the selector was added, our Engineering teams were all up in arms about having a giant list to scroll through each time.

For your argument about losing valuable data, there is nothing stopping you from adding an object type custom field to the Platform model to capture the Manufacturer of the OS vendor, or whatever you want to call it, which would allow you to leave the Manufacturer field blank and achieve your desired functionality without creating a product regression for others.

@sleepinggenius2 commented on GitHub (Mar 6, 2025): Your examples are for servers. As a service provider, we only have network equipment to document in our NetBox instance and all Platforms have a Manufacturer that matches the device Manufacturer. So, with all the different equipment vendors we use, having a couple values in the dropdown versus 60+ different values that you have to remember what the particular vendor's OS is called is a huge time savings and helps maintain data integrity. As we also tie platforms to integrations/automations, selecting the correct value is critical. I can tell you from experience that when this was broken back when the selector was added, our Engineering teams were all up in arms about having a giant list to scroll through each time. For your argument about losing valuable data, there is nothing stopping you from adding an object type custom field to the Platform model to capture the Manufacturer of the OS vendor, or whatever you want to call it, which would allow you to leave the Manufacturer field blank and achieve your desired functionality without creating a product regression for others.

adam commented

2025-12-29 21:36:43 +01:00

@empusas commented on GitHub (Mar 7, 2025):

Well, good for you if you only need to document network devices. However, many users deal with a broader range of infrastructure, where this is not the case.

Even then, I would assume you’ve encountered at least a few network vendors where the 1:1 relationship between hardware and OS does not apply. If not, here’s a quick list:
• SONiC runs on hardware from Dell, Arista, Cisco, Edgecore, Mellanox (NVIDIA), and Broadcom.
• OS10 runs on hardware from Dell and Big Switch Networks.
• EOS runs on hardware from Arista, Big Switch Networks, and even Dell.
• Comware runs on hardware from Huawei and H3C.
• VyOS runs on hardware from Ubiquiti, Vyatta, and MikroTik.
• Cumulus Linux runs on various white-box switches like Mellanox (NVIDIA), Dell, Edgecore, and HPE.

Just because you haven’t seen these combinations or your company doesn’t use them doesn’t mean they don’t exist for others.

BTW: There’s a search function in every dropdown—users don’t have to scroll manually. Or do your users also scroll through the entire device list in each form?

@empusas commented on GitHub (Mar 7, 2025): Well, good for you if you only need to document network devices. However, many users deal with a broader range of infrastructure, where this is not the case. Even then, I would assume you’ve encountered at least a few network vendors where the 1:1 relationship between hardware and OS does not apply. If not, here’s a quick list: • SONiC runs on hardware from Dell, Arista, Cisco, Edgecore, Mellanox (NVIDIA), and Broadcom. • OS10 runs on hardware from Dell and Big Switch Networks. • EOS runs on hardware from Arista, Big Switch Networks, and even Dell. • Comware runs on hardware from Huawei and H3C. • VyOS runs on hardware from Ubiquiti, Vyatta, and MikroTik. • Cumulus Linux runs on various white-box switches like Mellanox (NVIDIA), Dell, Edgecore, and HPE. Just because you haven’t seen these combinations or your company doesn’t use them doesn’t mean they don’t exist for others. BTW: There’s a search function in every dropdown—users don’t have to scroll manually. Or do your users also scroll through the entire device list in each form?

adam commented

2025-12-29 21:36:43 +01:00

@luteijn commented on GitHub (Mar 7, 2025):

Also, companies not infrequently get taken over, e.g. Bay, Nortel, Avaya, Extreme - but newer software still runs on older hardware.
If you're scrolling through a list in a GUI for more than a small correction, haven't you already lost the game? But even then, just showing the short list at first and a {I know what I'm doing, show all} button to give the option to add a non matching combination would give both camps what they think they need.
In my mind the data you want to enter should not be limited to some arbitrary criteria a priori, but only when you try to use it, you check if you have all you need. Of course, giving a warning that 'vendors don't match' is fine, but don't stop me from entering partial data, or force me to put in dummy or wrong data.

@luteijn commented on GitHub (Mar 7, 2025): Also, companies not infrequently get taken over, e.g. Bay, Nortel, Avaya, Extreme - but newer software still runs on older hardware. If you're scrolling through a list in a GUI for more than a small correction, haven't you already lost the game? But even then, just showing the short list at first and a {I know what I'm doing, show all} button to give the option to add a non matching combination would give both camps what they think they need. In my mind the data you want to enter should not be limited to some arbitrary criteria a priori, but only when you try to use it, you check if you have all you need. Of course, giving a warning that 'vendors don't match' is fine, but don't stop me from entering partial data, or force me to put in dummy or wrong data.

adam commented

2025-12-29 21:36:43 +01:00

@Domoninic commented on GitHub (Mar 12, 2025):

Your examples are for servers. As a service provider, we only have network equipment to document in our NetBox instance and all Platforms have a Manufacturer that matches the device Manufacturer. So, with all the different equipment vendors we use, having a couple values in the dropdown versus 60+ different values that you have to remember what the particular vendor's OS is called is a huge time savings and helps maintain data integrity. As we also tie platforms to integrations/automations, selecting the correct value is critical. I can tell you from experience that when this was broken back when the selector was added, our Engineering teams were all up in arms about having a giant list to scroll through each time.

When you create a Device does it inherit the Default Platform from the Device type ?
If you only ever need a 1:1 mapping of Platform to Device does this this not cover your needs ?

@Domoninic commented on GitHub (Mar 12, 2025): > Your examples are for servers. As a service provider, we only have network equipment to document in our NetBox instance and all Platforms have a Manufacturer that matches the device Manufacturer. So, with all the different equipment vendors we use, having a couple values in the dropdown versus 60+ different values that you have to remember what the particular vendor's OS is called is a huge time savings and helps maintain data integrity. As we also tie platforms to integrations/automations, selecting the correct value is critical. I can tell you from experience that when this was broken back when the selector was added, our Engineering teams were all up in arms about having a giant list to scroll through each time. > When you create a Device does it inherit the Default Platform from the Device type ? If you only ever need a 1:1 mapping of Platform to Device does this this not cover your needs ?

adam commented

2025-12-29 21:36:44 +01:00

@sleepinggenius2 commented on GitHub (Mar 13, 2025):

We have the Default Platform set on our Device Types, but have run into a number of challenges using it in practice. For example, we can't make platform a required field while relying on the default value, because the default is only set on the object during save(), but validators run on the post_clean signal. The default is also only set if the platform is not provided, and since platform is part of clone_fields on the Device object, if an Engineer is building out a new site and adds an IOS XR router, then clicks Create & Add Another to add an IOS XE switch, the platform will still say IOS XR unless they clear or change it. Usually they would just change it today, because it's about the same level of effort to pick the correct choice from the limited number of options. It's also not always a 1:1 mapping. For example, IOS XR 32-bit vs IOS XR 64-bit or IOS XR 6 vs IOS XR 7 are important distinctions and can usually run on the same Device Type, so the Default Platform would just be IOS XR and then we could use that in a custom validator to make sure that a more specific option was selected in a scalable way.

@sleepinggenius2 commented on GitHub (Mar 13, 2025): We have the Default Platform set on our Device Types, but have run into a number of challenges using it in practice. For example, we can't make platform a required field while relying on the default value, because the default is only set on the object during `save()`, but validators run on the `post_clean` signal. The default is also only set if the platform is not provided, and since platform is part of `clone_fields` on the Device object, if an Engineer is building out a new site and adds an IOS XR router, then clicks Create & Add Another to add an IOS XE switch, the platform will still say IOS XR unless they clear or change it. Usually they would just change it today, because it's about the same level of effort to pick the correct choice from the limited number of options. It's also not always a 1:1 mapping. For example, IOS XR 32-bit vs IOS XR 64-bit or IOS XR 6 vs IOS XR 7 are important distinctions and can usually run on the same Device Type, so the Default Platform would just be IOS XR and then we could use that in a custom validator to make sure that a more specific option was selected in a scalable way.

adam commented

2025-12-29 21:36:44 +01:00

@jeremystretch commented on GitHub (Mar 13, 2025):

The manufacturer field exists on the platform model specifically for this purpose: To limit the devices/VMs to which the platform may be assigned. I see no benefit to removing this functionality.

However, in the compute world, this is not the case. Your server hardware might be from Dell or Lenovo, while the operating system could be provided by Red Hat or Microsoft.

These are not manufacturers in this sense; they are software publishers. If you need to correlate a software platform to its publisher (which again, is not a function of the manufacturer field), this could be done via a custom field, tag, or plugin.

@jeremystretch commented on GitHub (Mar 13, 2025): The manufacturer field exists on the platform model specifically for this purpose: To limit the devices/VMs to which the platform may be assigned. I see no benefit to removing this functionality. > However, in the compute world, this is not the case. Your server hardware might be from Dell or Lenovo, while the operating system could be provided by Red Hat or Microsoft. These are not manufacturers in this sense; they are software publishers. If you need to correlate a software platform to its publisher (which again, is _not_ a function of the manufacturer field), this could be done via a custom field, tag, or plugin.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#10850