Open wycre opened 4 months ago
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 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 aOneToOneField
todcim.ModuleBay
. Here are the changes to the database that could make this work:dcim.Module
module_bay
field.dcim.ModuleBay
installed_module
ForeignKey
field pointed todcim.Module
installed_module
is empty by defaultWhen 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:
Database changes
dcim.Module
module_bay
field.dcim.ModuleBay
installed_module
ForeignKey
field pointed todcim.Module
installed_module
is empty by defaultExternal dependencies
No response