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

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

New Issue
Open
opened 2025-12-29 21:25:11 +01:00 by adam · 10 comments
adam commented 2025-12-29 21:25:11 +01:00
Owner
Copy Link

Originally created by @wycre on GitHub (Jul 12, 2024).

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.

  1. Create a device
  2. Give that device (3) module bays with positions 0, 1, 2
  3. Assign a module to a module bay
  4. Modules can only be assigned to position 0 or 1 or 2, not 0 AND 1

Cisco MF-1RU
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.

Dell M1000E
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

Originally created by @wycre on GitHub (Jul 12, 2024). ### 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. > 1. Create a device > 2. Give that device (3) module bays with positions 0, 1, 2 > 3. Assign a module to a module bay > 4. Modules can only be assigned to position 0 or 1 or 2, not 0 AND 1 > ![Cisco MF-1RU](https://user-images.githubusercontent.com/77940332/162767639-59d4d513-2d75-4c30-83fb-dea5d9575104.PNG) 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. > ![Dell M1000E](https://user-images.githubusercontent.com/77940332/162768619-262984c4-385b-43fd-818e-35c43a1473bd.PNG) 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_
adam added the type: featurecomplexity: mediumnetboxstatus: backlog labels 2025-12-29 21:25:11 +01:00
adam commented 2025-12-29 21:25:12 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 16, 2024):

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.

@sleepinggenius2 commented on GitHub (Jul 16, 2024): 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.
adam commented 2025-12-29 21:25:12 +01:00
Author
Owner
Copy Link

@wycre commented on GitHub (Jul 16, 2024):

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.

@wycre commented on GitHub (Jul 16, 2024): > 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.
adam commented 2025-12-29 21:25:12 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 16, 2024):

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.

@sleepinggenius2 commented on GitHub (Jul 16, 2024): > 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.
adam commented 2025-12-29 21:25:13 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jul 19, 2024):

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.

@jeffgdotorg commented on GitHub (Jul 19, 2024): 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.
adam commented 2025-12-29 21:25:13 +01:00
Author
Owner
Copy Link

@jjoves73 commented on GitHub (Apr 8, 2025):

I have something similar with Juniper MIC cards where the Module position is only 1 value. However the MIC can have multiple depending on the slot position (module bay) on the device. Here's an example.

Juniper MIC 3D-20GE SFP
this MIC card (module) goes on a another card with 2 Module Bays on it, which then install on a Module bay of a device.
The ports/interface are name as such it is broken in groups.

ge-{module}/{module}/[0-9] -- first 10 ports
ge-{module}/{module}+1/[0-9] -- second 10 ports

However that is only for the 1st 10 ports, the 2nd 10 ports the middle {module} is a different number. I was hoping to do {module} + 1 or whatever value we we add. So we wont have to change the position of the actual module.

@jjoves73 commented on GitHub (Apr 8, 2025): I have something similar with Juniper MIC cards where the Module position is only 1 value. However the MIC can have multiple depending on the slot position (module bay) on the device. Here's an example. Juniper MIC 3D-20GE SFP this MIC card (module) goes on a another card with 2 Module Bays on it, which then install on a Module bay of a device. The ports/interface are name as such it is broken in groups. ge-{module}/{module}/[0-9] -- first 10 ports ge-{module}/{module}+1/[0-9] -- second 10 ports However that is only for the 1st 10 ports, the 2nd 10 ports the middle {module} is a different number. I was hoping to do {module} + 1 or whatever value we we add. So we wont have to change the position of the actual module.
adam commented 2025-12-29 21:25:13 +01:00
Author
Owner
Copy Link

@marcusyuri commented on GitHub (May 9, 2025):

We have the same issue here. In some cases we have a specific module that occupies multiples modules bays. Right now the workaround soluction to document the ocuppation of the "other" modules bays is to use a fake module on it, and make a reference to the main module.

It would be a nice addition to NetBox framework!!!!

@marcusyuri commented on GitHub (May 9, 2025): We have the same issue here. In some cases we have a specific module that occupies multiples modules bays. Right now the workaround soluction to document the ocuppation of the "other" modules bays is to use a fake module on it, and make a reference to the main module. It would be a nice addition to NetBox framework!!!!
adam commented 2025-12-29 21:25:13 +01:00
Author
Owner
Copy Link

@rafaelcortesdepaiva commented on GitHub (May 9, 2025):

This feature would be a great improving to Netbox. Currently I did a workaround using two custom fields in the module type, where you can set the number of slots a linecard uses horizontally and vertically. Then, I use then on a custom validator script to block another linecard to be placed in a "empty slot" that another multislot linecard is already placed.

@rafaelcortesdepaiva commented on GitHub (May 9, 2025): This feature would be a great improving to Netbox. Currently I did a workaround using two custom fields in the module type, where you can set the number of slots a linecard uses horizontally and vertically. Then, I use then on a custom validator script to block another linecard to be placed in a "empty slot" that another multislot linecard is already placed.
adam commented 2025-12-29 21:25:14 +01:00
Author
Owner
Copy Link

@zeugni15002 commented on GitHub (Sep 12, 2025):

We’re experiencing the same issue in our company and also need this feature. Currently, we’ve renamed the first bay to "Bay 1 & 2" and removed the second one, but this isn’t the perfect solution.

It would be great to see a more effective way to address this in the future.

@zeugni15002 commented on GitHub (Sep 12, 2025): We’re experiencing the same issue in our company and also need this feature. Currently, we’ve renamed the first bay to "Bay 1 & 2" and removed the second one, but this isn’t the perfect solution. It would be great to see a more effective way to address this in the future.
adam commented 2025-12-29 21:25:15 +01:00
Author
Owner
Copy Link

@dcolomer89 commented on GitHub (Sep 19, 2025):

Yes, the same issue in our company. It would be great to see a way to address this in the future.

@dcolomer89 commented on GitHub (Sep 19, 2025): Yes, the same issue in our company. It would be great to see a way to address this in the future.
adam commented 2025-12-29 21:25:15 +01:00
Author
Owner
Copy Link

@991jo commented on GitHub (Dec 23, 2025):

I would also like to see this feature to model our DWDM system with all the different kinds and sizes of cards.

It might be beneficial to add a field to the module to specify, that this module needs a certain amount of module bays to fit into. E.g. some cards might need 2 bays and you can only save it, if both bays are assigned. This does not touch the whole question regarding which bays are used, but ensures, that at least the right amount is used and that one has to think about the further bays that are needed.

I think the enforcement of the positions e.g. that it uses the bay above/below/left/right is hard to do and might differ between devices in the same series. E.g. we are running Ribbon Apollo 9608 Shelfs for our DWDM. Those have 8 Slots in 2 columns and 4 rows, numbered top to bottom. There are some cards, that use up 2 slots above each other. so the would use e.g. u0 and u2, with u2 being the primary slot that is used for interface numbering on the module. However there is the 9624 shelf which is bigger and has all the slots rotated by 90 degrees and changed the numbering of the ports according to the pictures I have seen (we are not using this shelf). So in this case we would use u0 and u2 again, but this time u0 would be the primary slot used for numbering.

@991jo commented on GitHub (Dec 23, 2025): I would also like to see this feature to model our DWDM system with all the different kinds and sizes of cards. It might be beneficial to add a field to the module to specify, that this module needs a certain amount of module bays to fit into. E.g. some cards might need 2 bays and you can only save it, if both bays are assigned. This does not touch the whole question regarding which bays are used, but ensures, that at least the right amount is used and that one has to think about the further bays that are needed. I think the enforcement of the positions e.g. that it uses the bay above/below/left/right is hard to do and might differ between devices in the same series. E.g. we are running Ribbon Apollo 9608 Shelfs for our DWDM. Those have 8 Slots in 2 columns and 4 rows, numbered top to bottom. There are some cards, that use up 2 slots above each other. so the would use e.g. u0 and u2, with u2 being the primary slot that is used for interface numbering on the module. However there is the 9624 shelf which is bigger and has all the slots rotated by 90 degrees and changed the numbering of the ports according to the pictures I have seen (we are not using this shelf). So in this case we would use u0 and u2 again, but this time u0 would be the primary slot used for numbering.
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 complexity: medium netbox status: backlog 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#9979
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?