Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module Bay compatible Module Types validation #13699

Closed
marcusyuri opened this issue Sep 6, 2023 · 5 comments
Closed

Module Bay compatible Module Types validation #13699

marcusyuri opened this issue Sep 6, 2023 · 5 comments
Labels
pending closure Requires immediate attention to avoid being closed for inactivity type: feature Introduction of new functionality to the application

Comments

@marcusyuri
Copy link

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

@marcusyuri marcusyuri added the type: feature Introduction of new functionality to the application label Sep 6, 2023
@sleepinggenius2
Copy link
Contributor

sleepinggenius2 commented 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 Allow modules to contain module bays and modules to be parents of other modules. #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.

@shatt79
Copy link

shatt79 commented 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.

Copy link
Contributor

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 github-actions bot added the pending closure Requires immediate attention to avoid being closed for inactivity label Dec 12, 2023
@netbox-community netbox-community deleted a comment from lameslime Jan 4, 2024
Copy link
Contributor

github-actions bot commented 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 github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 3, 2024
@llamafilm
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
pending closure Requires immediate attention to avoid being closed for inactivity type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

4 participants