Allow modules/device bays to take up more than 1 position

NetBox version

v3.4.2

Feature type

Change to existing functionality

Proposed functionality

This is a duplicate of #9080 but provides more details.

Currently, dcim.Module contains a OneToOneField to dcim.ModuleBay. Here are the changes to the database that could make this work:

dcim.Module

Remove module_bay field.

dcim.ModuleBay

Add a nullable installed_module ForeignKey field pointed to dcim.Module
installed_module is empty by default

When a new module is installed, allow the user to select multiple module bays that the module will occupy (similar to cable creation allowing multiple terminations).

This system allows for modules to occupy bays that may be close physically but not logically (i.e. a 3x3 grid can support tall modules that fill slots 1 & 4 or wide modules that fill slots 1 & 2 without needing to implement a system to mark their physical locations)

Use case

The use case has been described very well in #9080, I will copy it here for posterity.

From @cyr0nk0r:

Many modules within chassis can occupy more than 1 slot. This change would allow NetBox to more accurately represent the users environment. This same requirement applies to device bays. For example, a Dell M1000e blade system has 'half height' and 'full height' blade servers. A 'full-height' blade would occupy more than 1 position within the chassis. There is currently no clean way to represent this configuration.

Create a device

Give that device (3) module bays with positions 0, 1, 2

Assign a module to a module bay

Modules can only be assigned to position 0 or 1 or 2, not 0 AND 1

We see here a Cisco MF-1RU. This would be device bays rather than module bays but the principle is the same. This MF-1RU has the capability to hold 4 slots. Positions 1, 2, 3, and 4. In this screenshot you have (2) Cisco NCS2K-MF-MPO-16LC's inserted. These are double height modules that occupy slots 1 AND 3, and 2 AND 4. However, in the MF-1RU directly below it, you have (1) Cisco NCS2K-MF-DEG-5 which occupies slot 1 only. Theoretically you could add (4) of these DEG-5 modules, but only (2) of the MPO-16LC modules. Currently, there is no way to signify in Netbox that the MPO-16LC occupies positions 1 and 3, and 2 and 4 of this 1RU bracket.

Now we have a Dell M1000E blade center chassis. As you can see, this chassis supports multiple different sizes of modules. Technically, the M1000E has 16 slots. Those 16 slots can be occupied by a standard blade, or it could be occupied by a full height blade, or it could even be occupied by a double width blade. Both the full height and double width blades occupy 2 slots.

Database changes

dcim.Module

Remove module_bay field.

dcim.ModuleBay

Add a nullable installed_module ForeignKey field pointed to dcim.Module
installed_module is empty by default

External dependencies

No response

I was just thinking about this and looking at a very similar solution! There is the problem of naming and which position to use in the {module} placeholder. My thought is that you would need some way to designate the "primary" bay to disambiguate that. An alternative would be to reuse the existing UI for adding a module, so you add it to one bay, which is used to populate the placeholder, then you can edit the module to assign it to additional bays.

An additional item I was thinking about was a field on the module type to set the number of bays that a module occupies, which could be used to limit the number of selections allowed in the form. That does make an assumption that all bays are created equal though, and might make more sense to implement as part of compatibility, like in #16902, or just as a "maximum" value.

In the example above, if you insert an NCS2K-MF-MPO-16LC module into an NCS2K-MF-1RU bracket, as shown, then it will occupy two slots, either 1 & 3 or 2 & 4, but if you insert it into an NCS2K-MF10-6RU shelf, then it will only occupy one slot, as that shelf has double-wide slots specifically for those modules. This actually brings up another point, which is that we model the first scenario with devices and device bays today, as they show as separate PUNIT entries in the device inventory, with their own port naming, but as modules in the second scenario, as they use their slot position within their parent shelf in their port naming instead. So, if we make this change for modules and module bays, I think it would make sense to do it for devices and device bays as well. Interestingly, device bays are already implemented with an installed_device field, so I believe that would just need to be changed from a OneToOneField to a ForeignKey and the related_name to _('parent_bays') from a model standpoint.

There is the problem of naming and which position to use in the {module} placeholder. My thought is that you would need some way to designate the "primary" bay to disambiguate that. An alternative would be to reuse the existing UI for adding a module, so you add it to one bay, which is used to populate the placeholder, then you can edit the module to assign it to additional bays.

That is something I had not thought of, I think your solution would add an extra step to installing the modules on account of the editing. Right now, I am importing a very large network into NetBox and installing modules already takes too many steps in my opinion (no way to bulk create modules in the GUI).

One solution is when creating modules, the user adds the module bays the module will occupy to a list in the form and the module bay object with the lowest id of the selected module bays would be the 'default' and used for the {module} placeholder.

That is something I had not thought of, I think your solution would add an extra step to installing the modules on account of the editing. Right now, I am importing a very large network into NetBox and installing modules already takes too many steps in my opinion (no way to bulk create modules in the GUI).

You can absolutely bulk create modules in the GUI by using the Module Bulk Import screen. I've loaded tens of thousands of modules from CSV that way, just need to do it in batches. The import form could be updated to add something like an additional_module_bays field to associate the additional bays and the existing module_bay field as the "primary" one used for naming.

One solution is when creating modules, the user adds the module bays the module will occupy to a list in the form and the module bay object with the lowest id of the selected module bays would be the 'default' and used for the {module} placeholder.

That definitely wouldn't work for us in all scenarios. We have some double-width cards that use the "lower" slot and some that use the "upper" slot for naming, because it depends on where they connect to the backplane. So, a card occupying slots 1 and 2, for example, might say that it is in slot 1 if the backplane connector is on the left (looking from the front), or in slot 2 if the backplane connector is on the right. Having the correct slot number would be critical to naming the interfaces correctly.

Thanks for your interest in helping improve NetBox, and for building upon the foundation laid by @cyr0nk0r in #9080.

I've moved this issue to backlog status and added needs milestone since the described database changes include the removal of an existing table, something best done at a minor or major version boundary. If there's sufficient interest, the team may assign it to a release milestone.

netbox-community / netbox