Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given. #11676

New Issue

adam · 2025-12-29T21:48:23+01:00

adam commented

2025-12-29 21:48:23 +01:00

Originally created by @Stingo77 on GitHub (Oct 2, 2025).

Originally assigned to: @mrmrcoleman on GitHub.

NetBox Edition

NetBox Community

NetBox Version

v.4.4.2

Python Version

3.11

Steps to Reproduce

Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card.
Create rear card with module bay Gi0/1/[1-4] position [1-4] for sfp module.
Insert rear card into device.
Insert sfp module in slot rear card.

Expected Behavior

The module will be inserted into the raer card and interface will be added.
Gi0/0/1 — — — — Gi0/0/1
Gi0/0/2 — — — — Gi0/0/2
Gi0/0/3 — — — — Gi0/0/3
Rear card slot — Generic-card-sfp — 1
Gi0/1/1 — — — — Gi0/1/1
Gi0/1/2 — — — — Gi0/1/2

Observed Behavior

The module is not added, an error is returned "Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given."

Originally created by @Stingo77 on GitHub (Oct 2, 2025). Originally assigned to: @mrmrcoleman on GitHub. ### NetBox Edition NetBox Community ### NetBox Version v.4.4.2 ### Python Version 3.11 ### Steps to Reproduce 1. Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card. 2. Create rear card with module bay Gi0/1/[1-4] position [1-4] for sfp module. 3. Insert rear card into device. 4. Insert sfp module in slot rear card. ### Expected Behavior The module will be inserted into the raer card and interface will be added. Gi0/0/1 — — — — Gi0/0/1 Gi0/0/2 — — — — Gi0/0/2 Gi0/0/3 — — — — Gi0/0/3 Rear card slot — Generic-card-sfp — 1 Gi0/1/1 — — — — Gi0/1/1 Gi0/1/2 — — — — Gi0/1/2 ### Observed Behavior The module is not added, an error is returned "Cannot install module with placeholder values in a module bay tree 2 in tree but 1 placeholders given."

adam added the type: bug status: accepted netbox severity: low labels 2025-12-29 21:48:23 +01:00

adam commented

2025-12-29 21:48:23 +01:00

@arthanson commented on GitHub (Oct 3, 2025):

@Stingo77 can you please expand on these steps (more details) esp step 1 "Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card." is not clear, but all the steps could use further detail.

@arthanson commented on GitHub (Oct 3, 2025): @Stingo77 can you please expand on these steps (more details) esp step 1 "Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card." is not clear, but all the steps could use further detail.

adam commented

2025-12-29 21:48:23 +01:00

@Stingo77 commented on GitHub (Oct 6, 2025):

@Stingo77 can you please expand on these steps (more details) esp step 1 "Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card." is not clear, but all the steps could use further detail.

I've created a sw-test device with module bay "Rear card slot" (1) and module bays Gi/0/1- Gi0/0/8.

I've created a module Generic-card-sfp with module bays Gi/1/1- Gi0/1/4. Installed the module into the device sw-test.

I've created a module Generic-SFP-1 with interface name {module}.

And then I insert the Generic-SFP-1 module into the module bay Gi/1/1 and get an error. This is necessary to account for sfp modules, as suggested in the use case "Modeling Pluggable Transceivers"

@Stingo77 commented on GitHub (Oct 6, 2025): > [@Stingo77](https://github.com/Stingo77) can you please expand on these steps (more details) esp step 1 "Create device with module bay Gi0/0/[1-24] position [1-24] for sfp module with intarface {module} and one module bay "Rear card slot" Position 1 for rear card." is not clear, but all the steps could use further detail. <img width="1134" height="860" alt="Image" src="https://github.com/user-attachments/assets/56511381-e604-40bf-8299-6de5b4799891" /> I've created a sw-test device with module bay "Rear card slot" (1) and module bays Gi/0/1- Gi0/0/8. <img width="739" height="453" alt="Image" src="https://github.com/user-attachments/assets/090e865c-5b32-4b79-986e-4e3985a26558" /> I've created a module Generic-card-sfp with module bays Gi/1/1- Gi0/1/4. Installed the module into the device sw-test. <img width="853" height="248" alt="Image" src="https://github.com/user-attachments/assets/91b725f5-f9ae-42fc-aecd-25ecd3ef0cea" /> I've created a module Generic-SFP-1 with interface name {module}. <img width="933" height="335" alt="Image" src="https://github.com/user-attachments/assets/7b0a60a8-973e-4c4f-836b-bdf09c566e2a" /> And then I insert the Generic-SFP-1 module into the module bay Gi/1/1 and get an error. This is necessary to account for sfp modules, as suggested in the use case "Modeling Pluggable Transceivers"

adam commented

2025-12-29 21:48:24 +01:00

@PortableProgrammer commented on GitHub (Oct 15, 2025):

I have run into this as well with nested module bays. In my example, I was modeling a Dell PowerEdge R340 with a PCIe riser (Riser 1) containing two PCIe slots (Riser {module}/PCIe [1-2]), each of which contained a dual-port SFP+ NIC. I did not model the SFPs, but instead modeled interfaces directly on the NIC, using the interface name {module}/[1-2]. Upon inserting the NIC into a PCIe slot located on a riser, I received the same error.

I worked around this by inserting another {module} token into the interface name: {module}/{module}/[1-2], which resulted in interfaces 1/2/1 and 1/2/2. This means, though, that I must now model two versions of this NIC, one for risers and one for no risers, since the two-token version will produce a similar error when inserted into a module bay one level higher.

In my use case, it would be easy enough to not model the risers and just model the resultant PCIe slots directly, since that's not a configuration item that changes frequently, but I hope it helps further illustrate the issue.

@PortableProgrammer commented on GitHub (Oct 15, 2025): I have run into this as well with nested module bays. In my example, I was modeling a Dell PowerEdge R340 with a PCIe riser (`Riser 1`) containing two PCIe slots (`Riser {module}/PCIe [1-2]`), each of which contained a dual-port SFP+ NIC. I did not model the SFPs, but instead modeled interfaces directly on the NIC, using the interface name `{module}/[1-2]`. Upon inserting the NIC into a PCIe slot located on a riser, I received the same error. I worked around this by inserting another `{module}` token into the interface name: `{module}/{module}/[1-2]`, which resulted in interfaces `1/2/1` and `1/2/2`. This means, though, that I must now model two versions of this NIC, one for risers and one for no risers, since the two-token version will produce a similar error when inserted into a module bay one level higher. In my use case, it would be easy enough to not model the risers and just model the resultant PCIe slots directly, since that's not a configuration item that changes frequently, but I hope it helps further illustrate the issue.

adam commented

2025-12-29 21:48:24 +01:00

@jonzey0 commented on GitHub (Oct 16, 2025):

We're essentially treating this issue as a blocker for us to migrate from using inventory items to module bays for SFPs. Until this is rectified, we're not going to be able to make the relevant changes from Inventory Items to Module Bays for transceivers at the scale needed.

In our environment we're looking at tracking the same SFPs across a number of devices, which may be line cards, or may be plugged directly into a device.

One of the things we'll be using is some automated tooling to pull some of these SFP details and having to account whether the SFPs is in a single line card, a nested line card, or plugged in directly would essentially require us to model three clones of the exact same SFP, defeating the purpose.

@jonzey0 commented on GitHub (Oct 16, 2025): We're essentially treating this issue as a blocker for us to migrate from using inventory items to module bays for SFPs. Until this is rectified, we're not going to be able to make the relevant changes from Inventory Items to Module Bays for transceivers at the scale needed. In our environment we're looking at tracking the same SFPs across a number of devices, which may be line cards, or may be plugged directly into a device. One of the things we'll be using is some automated tooling to pull some of these SFP details and having to account whether the SFPs is in a single line card, a nested line card, or plugged in directly would essentially require us to model three clones of the exact same SFP, defeating the purpose.

adam commented

2025-12-29 21:48:24 +01:00

@adparis99 commented on GitHub (Oct 16, 2025):

I concur with @jonzey0. I had planned to start using the suggested SFP modeling with some new equipment that is coming in, but it won't be feasible unless this works.

@adparis99 commented on GitHub (Oct 16, 2025): I concur with @jonzey0. I had planned to start using the suggested SFP modeling with some new equipment that is coming in, but it won't be feasible unless this works.

adam commented

2025-12-29 21:48:24 +01:00

@jeremystretch commented on GitHub (Oct 17, 2025):

@Stingo77 @PortableProgrammer @jonzey0 @adparis99 I've opened this for an owner. Would one of you like to volunteer a fix?

@jeremystretch commented on GitHub (Oct 17, 2025): @Stingo77 @PortableProgrammer @jonzey0 @adparis99 I've opened this for an owner. Would one of you like to volunteer a fix?

adam commented

2025-12-29 21:48:24 +01:00

@jonzey0 commented on GitHub (Oct 20, 2025):

I suspect at least some of the changes would need to be in the common.py file. At a start, changing the MODULE_TOKEN count from being an exact match

if len(module_bays) != template.name.count(MODULE_TOKEN):

to checking that you're not trying to install, say, a 2-level module in a 1-level bay

if len(module_bays) < template.name.count(MODULE_TOKEN):

At least allows the module to be installed in the above scenario (where you have a 1-Position Level Module going into a 2-Position Level Module bay).

The only problem though is this creates the interface with only the parent module position, and not the fully resolved set of positions. In the above case, you'd be able to install the first SFP, but the second SFP would violate the unique interface name constraint.

Example of what this currently looks like:-

My test device

My test modules

Line card template, where the naming of the card and the child interfaces is relative to the position

SFP where the port name is relative to the position

First populate the Line Cards and the SFPs going directly into the device (the current as-is setup)

Now with the above code change, I'm able to install an SFP into position "1/1"

However the Interface is named "1" rather than "1/1", which will mean if I try to install a second SFP in position 1/2, it will fail the validation

If my Test SFP Module has the Interface named {module}/{module}, this will be named "1/2" if populated into that slot. However this is the problem we're already looking at today (the same SFP type needing to be duplicated depending on whether it is in a line card or not)

Tried poking around to see whether I could find how to get the interface name to take the full name, but didn't have any luck.

I suspect it’s something to do with merging multiple positions together when you have an instance like this, but not sure how you’d handle it.

@jonzey0 commented on GitHub (Oct 20, 2025): I suspect at least some of the changes would need to be in the [common.py](https://github.com/netbox-community/netbox/blob/main/netbox/dcim/forms/common.py) file. At a start, changing the MODULE_TOKEN count from being an exact match `if len(module_bays) != template.name.count(MODULE_TOKEN):` to checking that you're not trying to install, say, a 2-level module in a 1-level bay `if len(module_bays) < template.name.count(MODULE_TOKEN):` At least allows the module to be installed in the above scenario (where you have a 1-Position Level Module going into a 2-Position Level Module bay). The only problem though is this creates the interface with only the parent module position, and not the fully resolved set of positions. In the above case, you'd be able to install the first SFP, but the second SFP would violate the unique interface name constraint. Example of what this currently looks like:- My test device <img width="957" height="340" alt="Image" src="https://github.com/user-attachments/assets/dad90f13-de0e-4a79-ae83-baab2a748631" /> My test modules Line card template, where the naming of the card and the child interfaces is relative to the position <img width="838" height="290" alt="Image" src="https://github.com/user-attachments/assets/61a47134-04cd-4d9b-b9cc-aa49a1c2c56c" /> SFP where the port name is relative to the position <img width="820" height="214" alt="Image" src="https://github.com/user-attachments/assets/41cb691f-9bcc-4a3e-a71a-b0c86ba99124" /> First populate the Line Cards and the SFPs going directly into the device (the current as-is setup) <img width="1328" height="511" alt="Image" src="https://github.com/user-attachments/assets/33599d83-3160-4560-bb56-45a1522901e7" /> <img width="921" height="249" alt="Image" src="https://github.com/user-attachments/assets/a5e9abe1-f6e9-4337-b323-8dc9a2f507f2" /> Now with the above code change, I'm able to install an SFP into position "1/1" <img width="1285" height="509" alt="Image" src="https://github.com/user-attachments/assets/535976fd-12ea-4fce-b57f-402959d648a8" /> However the Interface is named "1" rather than "1/1", which will mean if I try to install a second SFP in position 1/2, it will fail the validation <img width="904" height="321" alt="Image" src="https://github.com/user-attachments/assets/5fd41851-c448-426f-bb22-8e891cd55b1d" /> If my Test SFP Module has the Interface named {module}/{module}, this will be named "1/2" if populated into that slot. However this is the problem we're already looking at today (the same SFP type needing to be duplicated depending on whether it is in a line card or not) <img width="811" height="212" alt="Image" src="https://github.com/user-attachments/assets/47d0abd6-4f95-4b54-8043-5169e4231831" /> <img width="1268" height="553" alt="Image" src="https://github.com/user-attachments/assets/257fd063-7f83-467a-b95b-6d064b2b9378" /> <img width="904" height="339" alt="Image" src="https://github.com/user-attachments/assets/29b94b40-dc6d-481c-8446-8acf8cde132f" /> Tried poking around to see whether I could find how to get the interface name to take the full name, but didn't have any luck. I suspect it’s something to do with merging multiple positions together when you have an instance like this, but not sure how you’d handle it.

adam commented

2025-12-29 21:48:25 +01:00

@NSpikings-dB commented on GitHub (Nov 6, 2025):

@jonzey0 Has the possibility of using {module} in the position field been looked at as an option for this?
We've also encountered this issue when attempting to model switches with line cards with SFPs as modules.

As an example of this:

I've created a device type for the chassis:

And a module type for the line card where I've included {module} in the position field:

And an SFP with the interface name relative to the position:

Then I create a Device using these:

Obviously, the position value has not replaced {module}, but ideally, it would have used {module} in the same way as the name value. eg:

When installing an SFP, this would then simply take the 1/1 etc. position value, and look something like this:

@NSpikings-dB commented on GitHub (Nov 6, 2025): @jonzey0 Has the possibility of using {module} in the position field been looked at as an option for this? We've also encountered this issue when attempting to model switches with line cards with SFPs as modules. As an example of this: I've created a device type for the chassis: <img width="1051" height="487" alt="Image" src="https://github.com/user-attachments/assets/eead5f37-c775-4444-bfb2-c1ab5bf0591b" /> And a module type for the line card where I've included {module} in the position field: <img width="986" height="453" alt="Image" src="https://github.com/user-attachments/assets/299ac5c4-5c69-416d-9f3e-0b4346d4a3a2" /> And an SFP with the interface name relative to the position: <img width="780" height="340" alt="Image" src="https://github.com/user-attachments/assets/30d133cf-3399-47b5-9a6a-d20928c9c1ab" /> Then I create a Device using these: <img width="1025" height="860" alt="Image" src="https://github.com/user-attachments/assets/bc7000e7-b672-4312-b777-192dbceb6743" /> Obviously, the position value has not replaced {module}, but ideally, it would have used {module} in the same way as the name value. eg: <img width="962" height="818" alt="Image" src="https://github.com/user-attachments/assets/d6010214-e2af-4562-8deb-12f45ed2a75f" /> When installing an SFP, this would then simply take the 1/1 etc. position value, and look something like this: <img width="1050" height="504" alt="Image" src="https://github.com/user-attachments/assets/849756cf-707f-4b72-ad64-3edfa8f0c411" /> <img width="1048" height="502" alt="Image" src="https://github.com/user-attachments/assets/b54ecbe5-8e54-4960-9148-2a73152e4186" />

adam commented

2025-12-29 21:48:25 +01:00

@jonzey0 commented on GitHub (Nov 7, 2025):

@NSpikings-dB I suspect that this issue is somewhat intertwined with https://github.com/netbox-community/netbox/issues/20467 in the resolving of the position fields. With that being addressed, maybe the fix above would then be viable.

@jonzey0 commented on GitHub (Nov 7, 2025): @NSpikings-dB I suspect that this issue is somewhat intertwined with https://github.com/netbox-community/netbox/issues/20467 in the resolving of the position fields. With that being addressed, maybe the fix above would then be viable.

adam commented

2025-12-29 21:48:25 +01:00

@NSpikings-dB commented on GitHub (Nov 7, 2025):

@jonzey0 Yes, I think you're right. It looks like we would need both the work you have done, along with resolving {module} in the position field, to resolve this issue.

This is definitely a blocker for modelling several of our core devices at the moment unfortunately.

@NSpikings-dB commented on GitHub (Nov 7, 2025): @jonzey0 Yes, I think you're right. It looks like we would need both the work you have done, along with resolving {module} in the position field, to resolve this issue. This is definitely a blocker for modelling several of our core devices at the moment unfortunately.

adam commented

2025-12-29 21:48:26 +01:00

@Alex-Ignatov commented on GitHub (Nov 28, 2025):

Facing the same issue when trying to follow this modeling strategy: https://netboxlabs.com/docs/netbox/best-practices/modeling-pluggable-transceivers/#modeling-strategy

@Alex-Ignatov commented on GitHub (Nov 28, 2025): Facing the same issue when trying to follow this modeling strategy: https://netboxlabs.com/docs/netbox/best-practices/modeling-pluggable-transceivers/#modeling-strategy

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11676