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 #6322

New Issue
Closed
opened 2025-12-29 19:39:24 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:39:24 +01:00
Owner
Copy Link

Originally created by @ghost on GitHub (Apr 8, 2022).

NetBox version

v3.2.0

Feature type

Change to existing functionality

Proposed functionality

Currently, when selecting a module to fill a module bay, a module can only occupy 1 position at a time. There are instances where a chassis might have 8 module bays, but some modules can be wider than 1 module width and would occupy positions 1 & 2.
Same request to allow devices to occupy more than module device bay as the effect is functionally the same.

Use case

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.

Database changes

Allow modules to occupy multiple positions within module bays.

External dependencies

No response

Originally created by @ghost on GitHub (Apr 8, 2022). ### NetBox version v3.2.0 ### Feature type Change to existing functionality ### Proposed functionality Currently, when selecting a module to fill a module bay, a module can only occupy 1 position at a time. There are instances where a chassis might have 8 module bays, but some modules can be wider than 1 module width and would occupy positions 1 & 2. Same request to allow devices to occupy more than module device bay as the effect is functionally the same. ### Use case 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. ### Database changes Allow modules to occupy multiple positions within module bays. ### External dependencies _No response_
adam added the type: featurestatus: revisions needed labels 2025-12-29 19:39:24 +01:00
adam closed this issue 2025-12-29 19:39:24 +01:00
adam commented 2025-12-29 19:39:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 11, 2022):

Allow modules to occupy multiple positions within module bays.

Please elaborate on the proposed implementation. What specific changes to the schema are you suggesting?

@jeremystretch commented on GitHub (Apr 11, 2022): > Allow modules to occupy multiple positions within module bays. Please elaborate on the proposed implementation. What specific changes to the schema are you suggesting?
adam commented 2025-12-29 19:39:25 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 11, 2022):

  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

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.

2
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.

In summary, the change to the schema that I'm proposing is the ability for a module and/or device to occupy multiple positions within module bays and device bays.

@ghost commented on GitHub (Apr 11, 2022): 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 ![1](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. ![2](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. In summary, the change to the schema that I'm proposing is the ability for a module and/or device to occupy **multiple** positions within module bays and device bays.
adam commented 2025-12-29 19:39:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 11, 2022):

I think the use case is clear, but you've not addressed the database changes that would be needed to support it (you've merely described the desired functionality). Please have a look at how modules are currently being modeled, consider what you would change, and extend the "Database changes" section of your initial post above to include the proposed schema changes.

@jeremystretch commented on GitHub (Apr 11, 2022): I think the use case is clear, but you've not addressed the _database_ changes that would be needed to support it (you've merely described the desired functionality). Please have a look at how modules are currently being modeled, consider what you would change, and extend the "Database changes" section of your initial post above to include the proposed schema changes.
adam commented 2025-12-29 19:39:25 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 11, 2022):

I'm not a developer or a DBA. I have no idea how the database would need to be modified to support this.

@ghost commented on GitHub (Apr 11, 2022): I'm not a developer or a DBA. I have no idea how the database would need to be modified to support this.
adam commented 2025-12-29 19:39:26 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 11, 2022):

Yes, but you should also have a limited idea of how this should be implemented.

The other thing, is I don't know if you need to actually include the half or full designation. For example, on the NCS, those are likely all considered 1 slot, not a half slot. Likewise, on the N7706, the "slot" designation is arbitrary, when you have a 2 SUP2E's in slot 3 that take up half the slot each, they aren't Slot3.0 and Slot3.5, it is listed as "Slot 3" and "Slot 4".

Also, I don't think your blade center should be modeled as a Modular system, likely it should be modelled as a bay system similar to the UCS with some modules as they are likely all considered descrete devices.

@DanSheps commented on GitHub (Apr 11, 2022): Yes, but you should also have a limited idea of how this should be implemented. The other thing, is I don't know if you need to actually include the half or full designation. For example, on the NCS, those are likely all considered 1 slot, not a half slot. Likewise, on the N7706, the "slot" designation is arbitrary, when you have a 2 SUP2E's in slot 3 that take up half the slot each, they aren't Slot3.0 and Slot3.5, it is listed as "Slot 3" and "Slot 4". Also, I don't think your blade center should be modeled as a Modular system, likely it should be modelled as a bay system similar to the UCS with some modules as they are likely all considered descrete devices.
adam commented 2025-12-29 19:39:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2022):

Closing this out for now as the detail provided is insufficient. @cyr0nk0r if you'd like to involve additional members of the community to help flesh out your proposal, you're very welcome to do so. Once you have a rough idea for the database structure, please update your original post above and I'll be happy to re-open the issue.

@jeremystretch commented on GitHub (Apr 22, 2022): Closing this out for now as the detail provided is insufficient. @cyr0nk0r if you'd like to involve additional members of the community to help flesh out your proposal, you're very welcome to do so. Once you have a rough idea for the database structure, please update your original post above and I'll be happy to re-open the issue.
adam commented 2025-12-29 19:39:26 +01:00
Author
Owner
Copy Link

@shatt79 commented on GitHub (May 24, 2022):

I agree that this is needed. It bothers me when users are told to design the schema changes any time a new feature is proposed. Not all of us are DBAs or developers. I'm familiar with DBs, but I'm not familiar enough with the Netbox schema to understand all of the relationships and constraints that may exist that could determine whether or not a proposed change is even feasible or not.

When creating a module in the dcim_moduletype table, there should be column for "Module Width" or something. This integer would determine how many module bays are occupied by the module when it is installed. When that module is installed into a module bay, that module's ID should be set on all module bays that it occupies. Right now, a module has a 1:1 relationship with a module bay. For this to work, the module to module_bay relationship should be 1:n, where n is the module width.

If I create a module with a width of 2, then that module will occupy two adjacent module bays within a device, in an ascending manner. For example: Let's say I want to install a 2 wide module into a device with 10 slots. If I put that module into slot 1, it should occupy slots 1 and 2. If I put it into slot 8, it should occupy 8 and 9. Now, lets say I try to install a 2-wide module into a device that only has one open slot. In that case, the module insert should fail and return an error.

Here's a screenshot of another system we use that can perform the function we're talking about. There are 4 slots. Slots 21 and 23 are occupied by double-wide cards. Notice how slots 22 and 24 show that they are also occupied by the devices in 21 and 23.

image

@shatt79 commented on GitHub (May 24, 2022): I agree that this is needed. It bothers me when users are told to design the schema changes any time a new feature is proposed. Not all of us are DBAs or developers. I'm familiar with DBs, but I'm not familiar enough with the Netbox schema to understand all of the relationships and constraints that may exist that could determine whether or not a proposed change is even feasible or not. When creating a module in the dcim_moduletype table, there should be column for "Module Width" or something. This integer would determine how many module bays are occupied by the module when it is installed. When that module is installed into a module bay, that module's ID should be set on all module bays that it occupies. Right now, a module has a 1:1 relationship with a module bay. For this to work, the module to module_bay relationship should be 1:n, where n is the module width. If I create a module with a width of 2, then that module will occupy two adjacent module bays within a device, in an ascending manner. For example: Let's say I want to install a 2 wide module into a device with 10 slots. If I put that module into slot 1, it should occupy slots 1 and 2. If I put it into slot 8, it should occupy 8 and 9. Now, lets say I try to install a 2-wide module into a device that only has one open slot. In that case, the module insert should fail and return an error. Here's a screenshot of another system we use that can perform the function we're talking about. There are 4 slots. Slots 21 and 23 are occupied by double-wide cards. Notice how slots 22 and 24 show that they are also occupied by the devices in 21 and 23. ![image](https://user-images.githubusercontent.com/103387334/170073031-85a9f2b9-ff0b-458e-a5dc-446e3b775f0a.png)
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 status: revisions needed 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#6322
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?