Extend the behaviour of the {module} variable in components of module types to account for different module bay layouts

[sol1-matt]

NetBox version

v4.2.8

Feature type

Change to existing functionality

Proposed functionality

This is a FR related to #19414 to fulfil the request by arthanson .

The proposed functionality would allow for the definition of multiple naming conventions using {module} such that the same module type can be used with devices with in different levels of module bay configurations.

The implementation of this could be managed in different ways with the desired outcome to be the creation of values like

1 level:  port-1
2 levels: port-1-1
3 levels: port-1-1-1

Possible Implementations

List all possible combinations

port-{module},port-{module}-{module},port-{module}-{module}-{module}

Assume stop once all modules values are consumed

port-{module}-{module}-{module}

Regex optional repeat

port-{module}(-{module}){0,2}

Use case

The current functionality of module bays and module types correctly allows for nested designs

eg: device -> module bays -> module type -> module bays -> module type -> interface

A practical example of this would be a Server with a OCP bay (device -> module bay) which is filled with a dual port SFP nic (module type -> module bays), each port is then filled with a SFP module (module type -> interface).

For this to work in Netbox the SFP module needs to have the interface name set with 2 {module} variables
eg: port-{module}-{module}

However the same SFP module can not be used in another device which doesn't have this nested structure.

eg: device -> module bays -> module type -> interface

A practical example of this would be a Switch with SFP ports (module type -> module bays), each port is then filled with a SFP module (module type -> interface).

For this to work in Netbox the SFP module needs to have the interface name set with 1 {module} variable
eg: port-{module}

The Server and the Switch require different variables for the SFP Module which currently isn't possible.

The error message seen when trying to add a module type with the incorrect number of {module} vars for a given device configuration is
Cannot install module with placeholder values in a module bay tree <x> in tree but <y> placeholders given.

Workarounds

Duplicate Module Types
A work around to this would be to have multiple SFP Modules of the same type with different nesting vars for each one.

eg:
SFP Module (nest 1) = port-{module}
SFP Module (nest 2) = port-{module}-{module}
SFP Module (nest 3) = port-{module}-{module}-{module}

This can end up messy as you end up with multiple modules that are identical except for how they are used and requires the user to understand this specific problem/workaround.

Untick Replicate Components
When adding the module to a bay that has unsupported nesting untick the Replicate Components option and then manually create the interfaces and link them back to the correct bays.

This is additional work that isn't required when the {module} count matches with the potential for human error.

Alter the Module Type each time it is used in a different nesting format
Each time you get the error message Cannot install module with placeholder values in a module bay tree <x> in tree but <y> placeholders given. go to the Module Type and alter the {module} format to suit the current device.

This is additional work that isn't required when the {module} count matches but would need to be done each time the module is used on a device with nesting that is different from the last time it was used.

Reproducible test case

Types

• Create a Device Type Server with a OCP bay with 1 Module Bay named OCP
• Create a Device Type 24 port Switch with 2 Module Bays named SFP 1 and SFP 2 using positions 1 and 2
• Create a Module Type of Dual port SFP nic with 2 Module Bays named SFP 1 and SFP 2 using positions 1 and 2
• Create a Module Type of SFP module with a single interface name port-{module}

Server

• Create a Device with a Device Type of Server with a OCP bay
• Add a Module Type of Dual port SFP nic to the available OCP Module Bay
• Add a Module Type of SFP module to the SFP 1 Module Bay SFP 1, you will get error message
  Cannot install module with placeholder values in a module bay tree <x> in tree but <y> placeholders given.
• Change the Module Type of SFP module with a single interface name of port-{module} to have a interface name of port-{module}-{module}
• Add a Module Type of SFP module to the SFP 1 Module Bay SFP 1, it will work and create a interface linked to the module called port-1-1

Switch

• Create a Device with a Device Type of 24 port Switch
• Add a Module Type of SFP module to the SFP 1 Module Bay SFP 1, you will get error message
  Cannot install module with placeholder values in a module bay tree <x> in tree but <y> placeholders given.
• Change the Module Type of SFP module with a single interface name of port-{module}-{module} to have a interface name of port-{module}
• Add a Module Type of SFP module to the SFP 1 Module Bay SFP 1, it will work and create a interface linked to the module called port-1

Database changes

No response

External dependencies

No response

[smasharov]

just checked it on 4.3.1 and it's working, but I want some more functional.

for example I have Juniper FPC MX-MPC2E-3D-P and couple MIC-3D-4XGE-XFP installed in it.
template xe-{module}/{module}/[0-1] works, but the module MIC-3D-4XGE-XFP have two subnumbers: 0 and 1, and resulting numbers should be like {module}/{module*2}/[0-1] and {module}/{module*2+1}/[0-1]
I have tried syntax like {module+1} but it just not works at all, nothing happens then I try to install this type of module

[sol1-matt]

just checked it on 4.3.1 and it's working

I've checked 4.3.3 myself and I get exactly the same functionality as described originally. If the number of {module}'s vars don't match the module bay nesting in use on a given device the module can't be added.

[michaelmcdonald]

I have run into the same (frustrating) issue and am not sure of a good way forward. I attempted to utilize a script and tags on module creation that would detect if multiple {module} variables were needed but not there (or multiple {module} variables present but not needed) and correct accordingly; however that did not pan out.

@jeremystretch: is there a defined way to handle when multiple {module} variables are / are not needed and how we can accommodate that?

[jeremystretch]

Please stop pinging me for issues on which I have not engaged. I cannot and will not weigh in on every FR.

[michaelmcdonald]

Apologize; simply assumed as the lead developer you would have insight on how a situation like this is to be handled.

[TekunoKage]

SubModule Bay:

SubModule:

SubModule Lable Not Take Module Position:

SubModule Interfacce Definition

SubModule Interface Description Not populated

Netbox Version:
Community v4.3.3

On my case, just those few things need to be corrected to get this working properly.

Thanks!!!