starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Platform and Device must have the same Manufacturer #3796

New Issue
Closed
opened 2025-12-29 18:31:15 +01:00 by adam · 12 comments
adam commented 2025-12-29 18:31:15 +01:00
Owner
Copy Link

Originally created by @JulianJacobi on GitHub (Jun 19, 2020).

Environment

  • Python version: 3.7
  • NetBox version: 2.8.6

Steps to Reproduce

  1. Create a Manufacturer called "Dell"
  2. Create a DeviceType let's call it "R340" with Manufacturer "Dell"
  3. Create a Device "Random Dell Server" from DeviceType "R340"
  4. Create a Manufacturer called "RedHat"
  5. Create a Platform called "Red Hat Enterprise Linux" with Manufacturer "RedHat"
  6. Try to assign the Platform "Red Hat Enterprise Linux" to Device "Random Dell Server"

Expected Behavior

The Device "Random Dell Server" has now Platform "Red Hat Enterprise Linux" assigned.

Observed Behavior

The assignment is not possible because of a stupid check that says, that platforms must have the same manufacturer as the device they are assigned to.
How is it possible to correctly document any linux based server in Netbox?

I understand the check from an old networking point of view, it makes no sense to run JunOS on Cisco Routers, but in times of Cumulus Linux this check even fails for networking devices.

Originally created by @JulianJacobi on GitHub (Jun 19, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report, and that any plugins have been disabled. --> ### Environment * Python version: 3.7 * NetBox version: 2.8.6 <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. --> ### Steps to Reproduce 1. Create a `Manufacturer` called "Dell" 2. Create a `DeviceType` let's call it "R340" with `Manufacturer` "Dell" 3. Create a `Device` "Random Dell Server" from `DeviceType` "R340" 4. Create a `Manufacturer` called "RedHat" 5. Create a `Platform` called "Red Hat Enterprise Linux" with `Manufacturer` "RedHat" 6. Try to assign the `Platform` "Red Hat Enterprise Linux" to `Device` "Random Dell Server" <!-- What did you expect to happen? --> ### Expected Behavior The `Device` "Random Dell Server" has now `Platform` "Red Hat Enterprise Linux" assigned. <!-- What happened instead? --> ### Observed Behavior The assignment is not possible because of a stupid check that says, that platforms must have the same manufacturer as the device they are assigned to.\ How is it possible to correctly document any linux based server in Netbox? I understand the check from an old networking point of view, it makes no sense to run JunOS on Cisco Routers, but in times of Cumulus Linux this check even fails for networking devices.
adam closed this issue 2025-12-29 18:31:15 +01:00
adam commented 2025-12-29 18:31:15 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Jun 19, 2020):

Simple fix. Do NOT assign Redat Linux platform with a manufacturer, and it will be available to any server regardless of manufacturer.

Any platform that can run on multiple vendors equipment should not be assigned to a manufacturer. As for IOS, JunOS etc, it make sense to lock it down to specific manufacturer.

@ziggekatten commented on GitHub (Jun 19, 2020): Simple fix. Do NOT assign Redat Linux platform with a manufacturer, and it will be available to any server regardless of manufacturer. Any platform that can run on multiple vendors equipment should not be assigned to a manufacturer. As for IOS, JunOS etc, it make sense to lock it down to specific manufacturer.
adam commented 2025-12-29 18:31:15 +01:00
Author
Owner
Copy Link

@JulianJacobi commented on GitHub (Jun 19, 2020):

@ziggekatten do you really think it's a fix to not document things in a documentation system?

From my point of view this seems to be a little bit shitty. So I can only document the manufacturer of a platform if it's ever matching with the manufacturer of the assigned devices? Maybe i'm getting things wrong here, but for me this makes absolutely no sense.

@JulianJacobi commented on GitHub (Jun 19, 2020): @ziggekatten do you really think it's a fix to **not** document things in a documentation system? From my point of view this seems to be a little bit shitty. So I can only document the manufacturer of a platform if it's ever matching with the manufacturer of the assigned devices? Maybe i'm getting things wrong here, but for me this makes absolutely no sense.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@JulianJacobi commented on GitHub (Jun 19, 2020):

Additionally the manufacturer locking doesn't prevent you from wrong documentation at all, think about IOS XE and IOS XR both are Cisco platforms but can be installed only on specific Cisco devices.

So here we have a feature that prevents you in some special cases from misconfiguration, but also prevents you from document things completely. So think it's not a feature, it's a bug.

@JulianJacobi commented on GitHub (Jun 19, 2020): Additionally the manufacturer locking doesn't prevent you from wrong documentation at all, think about IOS XE and IOS XR both are Cisco platforms but can be installed only on specific Cisco devices. So here we have a feature that prevents you in some special cases from misconfiguration, but also prevents you from document things completely. So think it's not a feature, it's a bug.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Jun 19, 2020):

I think it is ”Good enough”, not perfect.

@ziggekatten commented on GitHub (Jun 19, 2020): I think it is ”Good enough”, not perfect.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@JulianJacobi commented on GitHub (Jun 19, 2020):

Question for me is: Whats the benefit of vendor locking?

There would be one, if e.g. all Cisco platform work with all Cisco devices (replace Cisco with random vendor), but because that's not the case i see no benefit in vendor locking.

@JulianJacobi commented on GitHub (Jun 19, 2020): Question for me is: Whats the benefit of vendor locking? There would be one, if e.g. all Cisco platform work with all Cisco devices (replace Cisco with random vendor), but because that's not the case i see no benefit in vendor locking.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Jun 19, 2020):

To minimize dropdown when you like us have 100+ manufacturers and 500+ device types

@ziggekatten commented on GitHub (Jun 19, 2020): To minimize dropdown when you like us have 100+ manufacturers and 500+ device types
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@JulianJacobi commented on GitHub (Jun 19, 2020):

IMHO not a problem with Select2 and the APISelect Widget

@JulianJacobi commented on GitHub (Jun 19, 2020): IMHO not a problem with Select2 and the APISelect Widget
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Jun 19, 2020):

Cisco alone have IOS, IOS XR, ACI 4.x ACI 5.x, Firepower etc. Minimizing stuff is essential.

Also, we have an archtecture tha continiously validate sanity of data and ensure that any deviations are handled. This is something everybody should consider. Never trust a user :-). This is where Netbox Custom scripts com in handy.

@ziggekatten commented on GitHub (Jun 19, 2020): Cisco alone have IOS, IOS XR, ACI 4.x ACI 5.x, Firepower etc. Minimizing stuff is essential. Also, we have an archtecture tha continiously validate sanity of data and ensure that any deviations are handled. This is something everybody should consider. Never trust a user :-). This is where Netbox Custom scripts com in handy.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@JulianJacobi commented on GitHub (Jun 19, 2020):

You were right if the sanity checking would make sense in this case, but like i showed before the vendor lock doesn't prevent users from selecting wrong stuff, so i think sanity checking is not really an argument here.

@JulianJacobi commented on GitHub (Jun 19, 2020): You were right if the sanity checking would make sense in this case, but like i showed before the vendor lock doesn't prevent users from selecting wrong stuff, so i think sanity checking is not really an argument here.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Jun 19, 2020):

Sanitychecks are definitively neccessary, especially when integrating with other systems such as ITSM and billing. In our case, we use netbox all the way out to our project managers and due dilligence people, that are not neccessarily the most technically skilled people, so verification is needed.

My point here is that you can either stumble on something that is not perfect, or one can look at how to use the tool in a way so that you business benefit from it.

For us the platform is used to estmimate and plan number of devices that need to be updated from x to y, and for various reports.

And again, nothing is perfect, but can be good enough.

@ziggekatten commented on GitHub (Jun 19, 2020): Sanitychecks are definitively neccessary, especially when integrating with other systems such as ITSM and billing. In our case, we use netbox all the way out to our project managers and due dilligence people, that are not neccessarily the most technically skilled people, so verification is needed. My point here is that you can either stumble on something that is not perfect, or one can look at how to use the tool in a way so that you business benefit from it. For us the platform is used to estmimate and plan number of devices that need to be updated from x to y, and for various reports. And again, nothing is perfect, but can be good enough.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Jun 19, 2020):

@JulianJacobi I'd recommend coming to a free and open-source project run by unpaid volunteers with a bit more civility in your language. We can be frustrated and have a debate without being rude.

@tyler-8 commented on GitHub (Jun 19, 2020): @JulianJacobi I'd recommend coming to a free and open-source project run by unpaid volunteers with a bit more civility in your language. We can be frustrated and have a debate without being rude.
adam commented 2025-12-29 18:31:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 20, 2020):

As others have pointed out, this is intentional. If it's not the behavior you want, NetBox isn't the right tool for you. Closing and locking.

@jeremystretch commented on GitHub (Jun 20, 2020): As others have pointed out, this is intentional. If it's not the behavior you want, NetBox isn't the right tool for you. Closing and locking.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3796
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?