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

Module Bay compatible Module Types validation #8578

New Issue
Closed
opened 2025-12-29 20:38:26 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:38:26 +01:00
Owner
Copy Link

Originally created by @marcusyuri on GitHub (Sep 6, 2023).

NetBox version

v3.6.0

Feature type

Data model extension

Proposed functionality

Create a new NetBox object type (suggestion name = Compatible Module Type) and associated UI that maps a specific module bay with all compatible module types that can be installed on that module bay.

The user edits the device type -> module bay, and select all compatible modules.
Netbox Image 1

The following picture is a UI concept example, made on Microsoft Paint:
Netbox Image 2

When the user try to install a new module, if the module bay has a compatible module object selection, the module type selection box will only display the compatible modules.
Netbox Image 3

Also, when the user clicks on 'save' module, netbox will validate if the module bay has a compatible module type list, and deny the save if the module is not allowed.

Use case

The Module Types table can have hundreds of modelled modules, from different vendors, and even from the same vendor. It was very easy to the user to select the wrong / incompatible module when population a device bay. For exemple, Cisco has two supervisor cards: ASR-1000-RP1 and ASR1000-RP3, that can be installed on module bay module R0 or module R1. The first one is compatible with the chassis (device type) ASR-1006, where the latter is compatible with the chassis ASR-1006X. The user can easily choose the wrong version or the supervisor card, or install the supervisor on the wrong module may (ex: module F0, that accepts Fabric only).

Database changes

I think that may be necessary to create a new table, that hosts a one to many relationship between a module bay template and a module type.

External dependencies

None

Originally created by @marcusyuri on GitHub (Sep 6, 2023). ### NetBox version v3.6.0 ### Feature type Data model extension ### Proposed functionality Create a new NetBox object type (suggestion name = Compatible Module Type) and associated UI that maps a specific module bay with all compatible module types that can be installed on that module bay. The user edits the device type -> module bay, and select all compatible modules. ![Netbox Image 1](https://github.com/netbox-community/netbox/assets/54281804/08bbd780-c645-4ae5-af68-af693cadc64e) The following picture is a UI concept example, made on **Microsoft Paint**: ![Netbox Image 2](https://github.com/netbox-community/netbox/assets/54281804/d2547e2b-acd1-4c19-a93f-743e324c8679) When the user try to install a new module, if the module bay has a compatible module object selection, the module type selection box will only display the compatible modules. ![Netbox Image 3](https://github.com/netbox-community/netbox/assets/54281804/98e332b8-78bd-4261-bd0b-c49691851229) Also, when the user clicks on 'save' module, netbox will validate if the module bay has a compatible module type list, and deny the save if the module is not allowed. ### Use case The Module Types table can have hundreds of modelled modules, from different vendors, and even from the same vendor. It was very easy to the user to select the wrong / incompatible module when population a device bay. For exemple, Cisco has two supervisor cards: **ASR-1000-RP1** and **ASR1000-RP3**, that can be installed on module bay **module R0** or **module R1**. The first one is compatible with the chassis (device type) **ASR-1006**, where the latter is compatible with the chassis **ASR-1006X**. The user can easily choose the wrong version or the supervisor card, or install the supervisor on the wrong module may (ex: **module F0**, that accepts Fabric only). ### Database changes I think that may be necessary to create a new table, that hosts a one to many relationship between a module bay template and a module type. ### External dependencies None
adam added the type: featurepending closure labels 2025-12-29 20:38:26 +01:00
adam closed this issue 2025-12-29 20:38:27 +01:00
adam commented 2025-12-29 20:38:27 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Sep 6, 2023):

Just throwing my two cents in on this. I've been working on a similar solution in our NetBox instance using a multi-object custom field on the Module Type to point to the compatible Module Bay Templates. Still working through the custom validator to enforce those compatibilities though. I had to implement it in this direction, because Template objects don't support custom fields. I wanted to highlight a few issues that I've run into with that implementation:

  1. Module Bays can be changed on the instance after the Device Type template is applied, so you may end up with Module Bays on a Device that have no compatibility defined within the Device Type. My current strategy is the permissive one to allow any module when there is no corresponding Module Bay Template.
  2. Without #10500 being implemented, things like your subslot example run into issues, unless you are able to include that within your Device Type model due to the way your network is configured. In our network, the MOD cards are only used sparingly on some older routers, so the subslots only exist on those Device instances and not on the Device Type. That leads to a lot of the above problem.
  3. Since the dropdown is not affected, you still see all the module types in the system, as the validation only occurs on save. So, it works from a data integrity standpoint, but not great for UX.
  4. The string representation for a Module Bay Template does not include the Device Type, so I had to hack that on in the code from a display standpoint. You also can't search on that part of the string, so it can make it difficult sometimes to find the correct Device Type and Module Bay Template.
  5. There is no link defined for a Module Bay Template today, so it displays in the UI as a string, but there is no way to directly navigate to the Template or Device Type.
  6. Our engineers identified some compatibilities that are based on not just the Module Bay, but also the software version of a device. That was not able to be addressed as part of my implementation, but it would be nice if there was a way to maybe optionally include Platform in the compatibility documentation as well.

Related to this, I also ended up needing to implement the same kind of thing for Device and Device Bays to document parent/child Device compatibility. That may need to be a separate feature request though.

@sleepinggenius2 commented on GitHub (Sep 6, 2023): Just throwing my two cents in on this. I've been working on a similar solution in our NetBox instance using a multi-object custom field on the Module Type to point to the compatible Module Bay Templates. Still working through the custom validator to enforce those compatibilities though. I had to implement it in this direction, because Template objects don't support custom fields. I wanted to highlight a few issues that I've run into with that implementation: 1. Module Bays can be changed on the instance after the Device Type template is applied, so you may end up with Module Bays on a Device that have no compatibility defined within the Device Type. My current strategy is the permissive one to allow any module when there is no corresponding Module Bay Template. 2. Without #10500 being implemented, things like your subslot example run into issues, unless you are able to include that within your Device Type model due to the way your network is configured. In our network, the MOD cards are only used sparingly on some older routers, so the subslots only exist on those Device instances and not on the Device Type. That leads to a lot of the above problem. 3. Since the dropdown is not affected, you still see all the module types in the system, as the validation only occurs on save. So, it works from a data integrity standpoint, but not great for UX. 4. The string representation for a Module Bay Template does not include the Device Type, so I had to hack that on in the code from a display standpoint. You also can't search on that part of the string, so it can make it difficult sometimes to find the correct Device Type and Module Bay Template. 5. There is no link defined for a Module Bay Template today, so it displays in the UI as a string, but there is no way to directly navigate to the Template or Device Type. 6. Our engineers identified some compatibilities that are based on not just the Module Bay, but also the software version of a device. That was not able to be addressed as part of my implementation, but it would be nice if there was a way to maybe optionally include Platform in the compatibility documentation as well. Related to this, I also ended up needing to implement the same kind of thing for Device and Device Bays to document parent/child Device compatibility. That may need to be a separate feature request though.
adam commented 2025-12-29 20:38:28 +01:00
Author
Owner
Copy Link

@shatt79 commented on GitHub (Sep 12, 2023):

This has been needed for awhile. I think I entered a feature request for this about 2 years ago.

At one point, it was fixed so only modules with the same vendor as the device would populate the dropdown. But that's not working anymore as of 3.5 or so.

@shatt79 commented on GitHub (Sep 12, 2023): This has been needed for awhile. I think I entered a feature request for this about 2 years ago. At one point, it was fixed so only modules with the same vendor as the device would populate the dropdown. But that's not working anymore as of 3.5 or so.
adam commented 2025-12-29 20:38:28 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 12, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 12, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:38:28 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 3, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Feb 3, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
adam commented 2025-12-29 20:38:28 +01:00
Author
Owner
Copy Link

@llamafilm commented on GitHub (Feb 26, 2024):

At one point, it was fixed so only modules with the same vendor as the device would populate the dropdown. But that's not working anymore as of 3.5 or so.

@shatt79 do you have any idea where I could find this "fixed" version? I think restricting it to the same manufacturer would be perfect. I found your old request #9106 that was closed.

@llamafilm commented on GitHub (Feb 26, 2024): > At one point, it was fixed so only modules with the same vendor as the device would populate the dropdown. But that's not working anymore as of 3.5 or so. @shatt79 do you have any idea where I could find this "fixed" version? I think restricting it to the same manufacturer would be perfect. I found your old request #9106 that was closed.
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 pending closure type: feature
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#8578
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?