Allow Model type drop-down selection filtering

[AnythingOverIP]

NetBox version

v3.7.6

Feature type

Data model extension

Proposed functionality

The current module population system in NetBox presents a challenge for users, as it displays all available module types regardless of their compatibility with the device type. When you populate a module in a device, the Module type drop-down menu can be challenging to use.

Suggested approach: Allow to specify which modules could be slotted in a given module bay (Think of it as a Module Kind list, a Module Candidate list or event a Module Whitelist). When creating a Module bay in a device type, allow a multi-selection field where you can specify which modules are compatible with that module bay (same field type as the Tags association one). The resulting list would then be used for the drop-down menu when populating the device. If no module type has been specified, allow any (like we can do today).

Use case

When you define a chassis device and populate the routing engine slot, only routing engines compatible with the device type would show up in the list. Then, on that same device, if you "slot in" an interface module, only interfaces modules that are supported would show up, not the hundreds of modules types you have in your NetBox instance.

Not only it would allow for a better user experience, it would be particularly helpful to ensure data quality. Some manufacturers have slight model number variations based on the device series (i.e a JPSU-550-DC-AFO for an EX4300 switch vs JPSU-550-C-DC-AFO for an EX4400 switch).

Database changes

Would require changes to accommodate the new model.

External dependencies

none

[jsenecal]

Modules are already filtered by manufacturer when adding them to a device by default, but I agree that defining arbitrary types of modules would benefit greatly the user base of netbox.

A ModuleKind model should be introduced (Subclassing OrganizationalModel)

One should keep in mind that a module bay should allow more than one type of module to be made compatible. (Many to many rel to ModuleKind) Quick example: Some SAS bays support SATA drives or NVMe; PCIe 16x slot supports PCIe 8x cards. etc. etc.

Module types should then have an optional Foreign key to ModuleKind model instances to define their "Kind"

Module bays with blank module kind field, accept everything, like the current implementation for backwards compatibility.

[sleepinggenius2]

We have something like this implemented in our environment today, but it only works from a validator standpoint, not a UI/UX standpoint, so it is far from ideal. We did this by adding a multiple object custom field to the device type and module type models for compatible bays: device bay templates for device type, and module bay templates for modules. We had to do it this way around, as you cannot currently add custom fields to a template object. We then have a custom validator that checks if the selected type is compatible with the template that generated the given bay. This has some more complex logic, as we have implemented an additional placeholder for shelf position, so that needs to be computed between the bay template name and the instantiated bay's name. So far, this works for device bays and top-level module bays, but breaks down for sub-modules, though that will hopefully start working once v4.1 gets released. Given the nested modules change slated for that release, it seems appropriate to also try to address compatibility. I would also love to see support for modules that consume multiple bays, but I know that's a separate FR.

@jsenecal, is your addition of a ModuleKind model just to allow different module types to be grouped together in some way for compatibility? I can see where that might just introduce additional complications versus adding compatibility with the type itself. For example, Power Supply A is compatible Device Type X and Y, but Power Supply B is only compatible with Device Type Y. If I'm understanding your model correctly, then Power Supply A would need to be given a ModuleKind like PS-XY (since it can only have one), and Power Supply B something like PS-Y, then you would need to make PS-XY compatible with Device Type X and [PS-XY, PS-Y] compatible with Device Type Y, which only gets more complicated if you end up with XZ, YZ, etc. combinations down the road, as more types are added. This could be dictated by technical limitations or business rules.

We also have another level of module compatibility that has been difficult to capture today, and that is when the compatibility is dependent on not just the bay, but the software version of the device. For example, we have some cards that require a minimum software version where support was added, so it would be nice if there was some way to take the Platform value into account as well.

Given both the technical limitations and the business rules that might come into play regarding compatibility, being able to specify a callback, like a custom validator, that could filter the type list before returning it through the API would be immensely beneficial. In our case, it would be almost the same logic as our validator, but with the added benefit of improving UX as well. This could potentially apply to any API result set to apply business rules, like certain equipment can only go in a particular rack or position in a rack. These are the same kind of things that can be implemented in validators today, but with that added UX benefit. For this specific use case, it would still be useful to establish models to capture compatibility relationships though, which could then be used in such a callback, or could drive a default callback implementation for the most common use case. If possible, some kind of more generic compatibility model would be ideal, which could cover more scenarios, like my rack position compatibility example.

[jsenecal]

Netbox is a 80/20 solution to most documentation problems. The idea that I proposed is to define a devicetype modulebay compatible kinds. This is finite and known upfront. You define a Kind, say QFX5100 Series Power supply. Create a psu of this kind, and only power supplies of this kind will be shown in the drop down.

You are describing a far more complex approach to this.

[AnythingOverIP]

Modules are already filtered by manufacturer when adding them to a device by default, but I agree that defining arbitrary types of modules would benefit greatly the user base of netbox.

@jsenecal : is it something that changed in 4.x? Is it an option to enable in config somewhere? Currently on my 3.7.6 instance, i get all my module types listed in the drop-down menu.

[jsenecal]

Modules are already filtered by manufacturer when adding them to a device by default, but I agree that defining arbitrary types of modules would benefit greatly the user base of netbox.

@jsenecal : is it something that changed in 4.x? Is it an option to enable in config somewhere? Currently on my 3.7.6 instance, i get all my module types listed in the drop-down menu.

Try it on the demo and select the proper manufacturer in the filter tool (button to the right)

I just noticed that the filter is there in the URL but not applied when first loading the form... This is a bug IMHO

[AnythingOverIP]

Try it on the demo and select the proper manufacturer in the filter tool (button to the right)

I wasn't a fan of that selector menu, but I just got convinced. I guess this is one more reason to upgrade to 4.x sooner than later. Merci! :)

[jeffgdotorg]

@thefreakquency I read the history here fairly attentively, but I'm not totally clear on whether your last comment indicates that you're withdrawing this FR, since it post-dates your most recent edit to the issue body. Could you please clarify for me where this stands in your mind?

[AnythingOverIP]

@jeffgdotorg : sorry if it wasn't clear. I still think this FR would bring a lot of value to the UI users: more efficient workflow and less chances of errors (Enhanced data quality).

The compromise suggestion, that @jsenecal made me realize is already implemented in 4.x, reduces the number of items in the drop-down menu. I won't see Nokia's or another manufacturer modules anymore when populating a Juniper chassis . I initially made that suggestion as this was not requiring any major changes.

The second approach might be harder to implement but would provide greater value to the user base. Being able to specify module candidates / module whitelist / Module Kind (call it the way it makes more sense) for a module bay would reduce the risk of user error (I've seen a few times errors like a user populating a power supply in a fan-tray only spot... ), and speed up the process (no need to scroll and analyze a list of cryptic model number to ensure you are populating THE one compatible with the device type and the module bay of that device.

[jeffgdotorg]

@thefreakquency thanks for summarizing. Please update your issue body to read against a 4.0 release, and to remove any parts that are not applicable in that release train. This will make it easier for the team to evaluate when populating the product backlog. Once that's done I'm happy to move your issue out of triage.

[jeffgdotorg]

Thanks for the edits @thefreakquency.

I've moved this issue to needs owner status. If you're interested in working it through to a PR, please leave a comment to that effect and a maintainer will assign it to you for implementation. Otherwise, another developer with the necessary skills and capacity can pick it up.

[AnythingOverIP]

Thanks @jeffgdotorg! Unfortunately i am more of a script kiddy than a developer. If it was a simple and obvious fix i could have attempted to do it but I don't want to add burden by submitting low-quality code for something that involve expanding the data model. 😬

[github-actions[bot]]

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]]

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.