Separate Hardware and Platform Manufacturers to allow Platforms by different vendors on hardware not produced by that vendor #1946

New Issue

adam · 2025-12-29T17:20:48+01:00

adam commented

2025-12-29 17:20:48 +01:00

Originally created by @JNR8 on GitHub (Aug 16, 2018).

Environment

Python version: 3.x (migrated to v3 yesterday so should be latest version)
NetBox version: 2.4.3

Proposed Functionality

Allow an additional Manufacturer to be selected for Platforms within a device. This would avoid the issue above and still limit the list of available Platforms to the select Manufacturer as originally requested in #1744

Use Case

Dell R630 device with Dell selected as the Manufacturer with VMWare ESXi Platform installed.

Database Changes

Possibly, as this would need a new field to be present on the Device form with the appropriate logic to filter our Platforms for that Manufacturer. but this may not need much, if any Db changes to achieve it.

External Dependencies

None that I know of.

Originally created by @JNR8 on GitHub (Aug 16, 2018). ### Environment * Python version: 3.x (migrated to v3 yesterday so should be latest version) * NetBox version: 2.4.3 ### Proposed Functionality Allow an additional Manufacturer to be selected for Platforms within a device. This would avoid the issue above and still limit the list of available Platforms to the select Manufacturer as originally requested in #1744 ### Use Case Dell R630 device with Dell selected as the Manufacturer with VMWare ESXi Platform installed. ### Database Changes Possibly, as this would need a new field to be present on the Device form with the appropriate logic to filter our Platforms for that Manufacturer. but this may not need much, if any Db changes to achieve it. ### External Dependencies None that I know of.

adam closed this issue

2025-12-29 17:20:48 +01:00

adam commented

2025-12-29 17:20:49 +01:00

@jeremystretch commented on GitHub (Aug 16, 2018):

I think the goal of allowing a platform to be associated with a manufacturer is specifically to enforce this limitation. In this case it would make sense to not treat VMware as a manufacturer, and simply refer to the platform as "VMware ESXi."

@jeremystretch commented on GitHub (Aug 16, 2018): I think the goal of allowing a platform to be associated with a manufacturer is specifically to enforce this limitation. In this case it would make sense to not treat VMware as a manufacturer, and simply refer to the platform as "VMware ESXi."

adam commented

2025-12-29 17:20:49 +01:00

@JNR8 commented on GitHub (Aug 17, 2018):

So I would have to create VMWare ESXi as a platform for all Manufacturers on which you run that platform? I.e HP and Dell amongst other.

The same issue arises for windows and all its variants running on physical hardware.

I suppose I could remove the associated manufacturer from the platform but then I’d end up with a long list of platforms for all devices, which essentially undoes what the original request to restrict that list was intending.

I don’t have to do this for VMs, so I’d expect the same hardware devices.

Chris Jenner

On 16 Aug 2018, at 16:34, Jeremy Stretch notifications@github.com wrote:

I think the goal of allowing a platform to be associated with a manufacturer is specifically to enforce this limitation. In this case it would make sense to not treat VMware as a manufacturer, and simply refer to the platform as "VMware ESXi."

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@JNR8 commented on GitHub (Aug 17, 2018): So I would have to create VMWare ESXi as a platform for all Manufacturers on which you run that platform? I.e HP and Dell amongst other. The same issue arises for windows and all its variants running on physical hardware. I suppose I could remove the associated manufacturer from the platform but then I’d end up with a long list of platforms for all devices, which essentially undoes what the original request to restrict that list was intending. I don’t have to do this for VMs, so I’d expect the same hardware devices. Chris Jenner > On 16 Aug 2018, at 16:34, Jeremy Stretch <notifications@github.com> wrote: > > I think the goal of allowing a platform to be associated with a manufacturer is specifically to enforce this limitation. In this case it would make sense to not treat VMware as a manufacturer, and simply refer to the platform as "VMware ESXi." > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread.

adam commented

2025-12-29 17:20:49 +01:00

@jeremystretch commented on GitHub (Aug 17, 2018):

So I would have to create VMWare ESXi as a platform for all Manufacturers on which you run that platform? I.e HP and Dell amongst other.

Yes, because ESXi is not inherently bound to any particular manufacturer. This is contrast to a platform like Junos, which (typically) runs only on hardware manufactured by Juniper.

@jeremystretch commented on GitHub (Aug 17, 2018): > So I would have to create VMWare ESXi as a platform for all Manufacturers on which you run that platform? I.e HP and Dell amongst other. Yes, because ESXi is not inherently bound to any particular manufacturer. This is contrast to a platform like Junos, which (typically) runs only on hardware manufactured by Juniper.

adam commented

2025-12-29 17:20:50 +01:00

@JNR8 commented on GitHub (Aug 20, 2018):

I would disagree there. Whilst some platforms are created by hardware vendors, a lot are not. In these cases they may be called something like "Software Vendors" or "Developers". I would suggest "Vendor" covers both hardware and software creators for all platform types. I can see why you have a Manufacturer type in NetBox, allowing for Device templates to be associated with a Hardware Manufacturer. But, in my experience, most Data Centers will predominantly have more devices with platforms not created by the hardware manufacturer than not. (i.e. Hypervisors, Windows, Linux, Unix Platforms running on a variety of different hardware types).

Currently creating Platforms with no associated Hardware Manufacturer undoes the change requested in #1744 by listing all platforms unrelated to the hardware selected.

To more accurately document platforms I believe removing their link to the hardware manufacturer field and instead creating a new field (called "platform vendor" for example) so that you can accurately document vendors for platforms, fulfill the requested function change in #1744 and allow for completely documenting all environment types.

Not being able to set a Vendor for soo many platforms sets my OCD twitching. It also seems to be at odds with creating a system to accurately document Data Center Environments.

@JNR8 commented on GitHub (Aug 20, 2018): I would disagree there. Whilst some platforms are created by hardware vendors, a lot are not. In these cases they may be called something like "Software Vendors" or "Developers". I would suggest "Vendor" covers both hardware and software creators for all platform types. I can see why you have a Manufacturer type in NetBox, allowing for Device templates to be associated with a Hardware Manufacturer. But, in my experience, most Data Centers will predominantly have more devices with platforms not created by the hardware manufacturer than not. (i.e. Hypervisors, Windows, Linux, Unix Platforms running on a variety of different hardware types). Currently creating Platforms with no associated Hardware Manufacturer undoes the change requested in #1744 by listing all platforms unrelated to the hardware selected. To more accurately document platforms I believe removing their link to the hardware manufacturer field and instead creating a new field (called "platform vendor" for example) so that you can accurately document vendors for platforms, fulfill the requested function change in #1744 and allow for completely documenting all environment types. Not being able to set a Vendor for soo many platforms sets my OCD twitching. It also seems to be at odds with creating a system to accurately document Data Center Environments.

adam commented

2025-12-29 17:20:50 +01:00

@LuPo commented on GitHub (Jan 24, 2019):

Hello Jeremy, likewise many others I really do appreciate your job. I would like to reopen a conversation on this topic and ask you to consider this problem looking on network devices instead.
In our data centers we are putting a lot of whitebox/capable routers from different major networking manufacturers. Without referring here to any specific brand name, it seams that there is a big advantage in terms of automation and operations in using a single NOS on networking devices from different vendors.
Wouldn't it make sense to create a relationship of "one to many" between a "platform" and a "manufacturer"?

@LuPo commented on GitHub (Jan 24, 2019): Hello Jeremy, likewise many others I really do appreciate your job. I would like to reopen a conversation on this topic and ask you to consider this problem looking on network devices instead. In our data centers we are putting a lot of whitebox/capable routers from different major networking manufacturers. Without referring here to any specific brand name, it seams that there is a big advantage in terms of automation and operations in using a single NOS on networking devices from different vendors. Wouldn't it make sense to create a relationship of "one to many" between a "platform" and a "manufacturer"?

adam commented

2025-12-29 17:20:50 +01:00

@timber-schroeder commented on GitHub (Feb 7, 2019):

Just chiming in that I have the exact same issues and requests as other people above. We have a lot of switches from different manufacturers running the same NOS distribution. While it would be possible to just decouple the platform from the manufacturer, that feels like a subpar solution, especially for instances where there are multiple platforms from a single software vendor in use.

What would be nice is if we could have a new field for manufacturers that tells if they are vendors for software, hardware or both. This would decouple the hardware manufacturers from the platform, which are very often unrelated to each other. As it is, creating multiple identical platforms just so that we can add those platforms to devices of differing manufacturers is a hacky solution.

Ideally we could then store version information on platforms and tie in those platforms with the services (service templates?) on individual devices, but I feel that that should be a separate issue.

@timber-schroeder commented on GitHub (Feb 7, 2019): Just chiming in that I have the exact same issues and requests as other people above. We have a lot of switches from different manufacturers running the same NOS distribution. While it would be possible to just decouple the platform from the manufacturer, that feels like a subpar solution, especially for instances where there are multiple platforms from a single software vendor in use. What would be nice is if we could have a new field for manufacturers that tells if they are vendors for software, hardware or both. This would decouple the hardware manufacturers from the platform, which are very often unrelated to each other. As it is, creating multiple identical platforms just so that we can add those platforms to devices of differing manufacturers is a hacky solution. Ideally we could then store version information on platforms and tie in those platforms with the services (service templates?) on individual devices, but I feel that that should be a separate issue.

adam commented

2025-12-29 17:20:50 +01:00

@mbaybarsk commented on GitHub (Aug 23, 2019):

Yes this is really causing me a headache.

I have several Hyper-V clusters and the "devices" that make up the nodes of the clusters are "HP" and I can't select "Server 2016" as a platform because it's a Microsoft product. This makes no sense for servers, only for networking equipment.

@mbaybarsk commented on GitHub (Aug 23, 2019): Yes this is really causing me a headache. I have several Hyper-V clusters and the "devices" that make up the nodes of the clusters are "HP" and I can't select "Server 2016" as a platform because it's a Microsoft product. This makes no sense for servers, only for networking equipment.

adam commented

2025-12-29 17:20:51 +01:00

@aventrax commented on GitHub (Oct 4, 2019):

Same here, I have physical servers from HP (Manufacturer=HP) with Windows installed (Platform=Microsoft), but I replicate this on Netbox, really a pity :(

@aventrax commented on GitHub (Oct 4, 2019): Same here, I have physical servers from HP (Manufacturer=HP) with Windows installed (Platform=Microsoft), but I replicate this on Netbox, really a pity :(

adam commented

2025-12-29 17:20:51 +01:00

@Blackraz0r commented on GitHub (Dec 19, 2019):

+1 Same Issue here.
Have multiple Servers from Dell, HP and some Whiteboxes running 2 V-Sphere cluster.

Would be nice to have the ability to put Dell as the Manu for the server, VMWare as the manu/dev/whatever of the Operating System.

unfortunately Jeremy never hat this case and/or rageclosed the thread after recieving 2 downvotes for his descision in :

So I would have to create VMWare ESXi as a platform for all Manufacturers on which you run that platform? I.e HP and Dell amongst other.

Yes, because ESXi is not inherently bound to any particular manufacturer. This is contrast to a platform like Junos, which (typically) runs only on hardware manufactured by Juniper.

so @jeremystretch maybe u like to reconsider to let the user decide (maybe via a setting) if he want to be dell or vmware the manufacturer of the operating system?

@Blackraz0r commented on GitHub (Dec 19, 2019): +1 Same Issue here. Have multiple Servers from Dell, HP and some Whiteboxes running 2 V-Sphere cluster. Would be nice to have the ability to put Dell as the Manu for the server, VMWare as the manu/dev/whatever of the Operating System. unfortunately Jeremy never hat this case and/or rageclosed the thread after recieving 2 downvotes for his descision in : > > So I would have to create VMWare ESXi as a platform for all Manufacturers on which you run that platform? I.e HP and Dell amongst other. > > Yes, because ESXi is not inherently bound to any particular manufacturer. This is contrast to a platform like Junos, which (typically) runs only on hardware manufactured by Juniper. so @jeremystretch maybe u like to reconsider to let the user decide (maybe via a setting) if he want to be dell or vmware the manufacturer of the operating system?

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#1946