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 to contain module bays and modules to be parents of other modules. #7040

New Issue
Closed
opened 2025-12-29 19:48:13 +01:00 by adam · 16 comments
adam commented 2025-12-29 19:48:13 +01:00
Owner
Copy Link

Originally created by @roadracer96 on GitHub (Sep 28, 2022).

Originally assigned to: @arthanson on GitHub.

NetBox version

v3.3.4

Feature type

Change to existing functionality

Proposed functionality

Some network devices have line cards inserted into slots that provide sub-slots.

Example: Juniper MX Chassis
FPC0 - Line card module
-- MIC0 - Sub-module
-- -- PIC0 - Sub-Sub-module
-- -- -- Interface et-0/0/0
-- MIC1 - Sub-module
-- -- PIC2 - Sub-Sub-module
-- -- -- Interface et-0/2/0
-- -- -- Interface et-0/2/1

Thought would need to be put into using the {module} variable in a nested fashion to permit automatic addition of interfaces based on the module template. In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. But from a pure inventory standpoint, having the ability to populate these the way some network devices see them would be very useful.

Use case

Inventory, Generation of interfaces from templates, modeling device configurations.

Database changes

No response

External dependencies

No response

Originally created by @roadracer96 on GitHub (Sep 28, 2022). Originally assigned to: @arthanson on GitHub. ### NetBox version v3.3.4 ### Feature type Change to existing functionality ### Proposed functionality Some network devices have line cards inserted into slots that provide sub-slots. Example: Juniper MX Chassis FPC0 - Line card module -- MIC0 - Sub-module -- -- PIC0 - Sub-Sub-module -- -- -- Interface et-0/0/0 -- MIC1 - Sub-module -- -- PIC2 - Sub-Sub-module -- -- -- Interface et-0/2/0 -- -- -- Interface et-0/2/1 Thought would need to be put into using the {module} variable in a nested fashion to permit automatic addition of interfaces based on the module template. In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. But from a pure inventory standpoint, having the ability to populate these the way some network devices see them would be very useful. ### Use case Inventory, Generation of interfaces from templates, modeling device configurations. ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: featurecomplexity: high labels 2025-12-29 19:48:13 +01:00
adam closed this issue 2025-12-29 19:48:13 +01:00
adam commented 2025-12-29 19:48:14 +01:00
Author
Owner
Copy Link

@mmfreitas commented on GitHub (Sep 28, 2022):

I did asked about nesting modules when modules were being implemented, but this is not supported, you can check #7844 if you need more information.

Since then I've been using a work around, I have been creating this nesting level by simply adding a module bay with the nested position to the device / device type.
This way you have a high level of costumization.

For ex:
Slot 0 = Position "0"

  • Sub-Slot 0 = Position "0/0"
    • Sub-Sub-Slot 0 = Position "0/0/0"

In reality these are 3 different slots, but you can manage some level of nesting using this logic, also keep in mind that netbox is not an inventory system, and you should not use modules for asset tracking.

@mmfreitas commented on GitHub (Sep 28, 2022): I did asked about nesting modules when modules were being implemented, but this is not supported, you can check #7844 if you need more information. Since then I've been using a work around, I have been creating this nesting level by simply adding a module bay with the nested position to the device / device type. This way you have a high level of costumization. For ex: Slot 0 = Position "0" - Sub-Slot 0 = Position "0/0" - Sub-Sub-Slot 0 = Position "0/0/0" In reality these are 3 different slots, but you can manage some level of nesting using this logic, also keep in mind that netbox is not an inventory system, and you should not use modules for asset tracking.
adam commented 2025-12-29 19:48:14 +01:00
Author
Owner
Copy Link

@roadracer96 commented on GitHub (Sep 28, 2022):

That is what I am doing in the interim. The problem is, you cant appropriately name template interfaces on the sub-slots. I thought that it may be a beneficial feature/add to have a flexible module design that allows unlimited nesting.

@roadracer96 commented on GitHub (Sep 28, 2022): That is what I am doing in the interim. The problem is, you cant appropriately name template interfaces on the sub-slots. I thought that it may be a beneficial feature/add to have a flexible module design that allows unlimited nesting.
adam commented 2025-12-29 19:48:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 28, 2022):

This idea has already been raised under #9107, however no detailed implementation was proposed. This issue also does not provide any substantial detail. Please flesh out your proposal to include the necessary details, especially the proposed database changes, so that they can be considered and discussed.

@jeremystretch commented on GitHub (Sep 28, 2022): This idea has already been raised under #9107, however no detailed implementation was proposed. This issue also does not provide any substantial detail. Please flesh out your proposal to include the necessary details, especially the proposed database changes, so that they can be considered and discussed.
adam commented 2025-12-29 19:48:14 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Sep 30, 2022):

I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example.

I think there's a couple of things that needs to be decided:

Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario:

  • We could either let the user specify the template variable name on the module, so the user could enter fpc for the FPC, mic for the MIC and pic for the pic. Then the templated interface on the PIC could be xe-{fpc}/{mic}/{pic} where we just follow the parent relationship until we reach the root module, gathering the template names and the positions.
  • Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc.
  • A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement.

Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under Add components.

@kkthxbye-code commented on GitHub (Sep 30, 2022): I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example. I think there's a couple of things that needs to be decided: Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario: * We could either let the user specify the template variable name on the module, so the user could enter `fpc` for the FPC, `mic` for the MIC and `pic` for the pic. Then the templated interface on the PIC could be `xe-{fpc}/{mic}/{pic}` where we just follow the parent relationship until we reach the root module, gathering the template names and the positions. * Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc. * A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement. Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under `Add components`.
adam commented 2025-12-29 19:48:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 4, 2022):

Let's keep the discussion focused on the proposed implementation. If you don't have anything of substance to add, please refrain from commenting.

@jeremystretch commented on GitHub (Oct 4, 2022): Let's keep the discussion focused on the proposed implementation. If you don't have anything of substance to add, please refrain from commenting.
adam commented 2025-12-29 19:48:14 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 4, 2022):

I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example.

I think there's a couple of things that needs to be decided:

Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario:

  • We could either let the user specify the template variable name on the module, so the user could enter fpc for the FPC, mic for the MIC and pic for the pic. Then the templated interface on the PIC could be xe-{fpc}/{mic}/{pic} where we just follow the parent relationship until we reach the root module, gathering the template names and the positions.
  • Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc.
  • A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement.

Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under Add components.

I don't believe unlimited nesting would be good for anyone. But we must also consider that if we say 1 level is ok, but 2 or 3 or 4 levels isn't .. inevitably someone is going to say "why can't I go 2 or 3 levels deep, my hardware works like that"

If we were to perhaps strike a balance of allowing maybe 2 layers deep? I have not seen any equipment in my years that has a module that goes into a module that goes into a module that goes into a module :D

The Cisco ASR 9K for example has power supplies that go into a Power Module .. that power module then goes into the Chassis. Can anyone offer examples where you would need 3 levels deep?

@ghost commented on GitHub (Oct 4, 2022): > I have looked at this in the past, and am still considering implementing it as we use Juniper devices like the ones in your example. > > I think there's a couple of things that needs to be decided: > > Are we to support unlimited nesting and how are we templating the position? If we are to support unlimited nesting, we need to figure out how to do the templating. Imagine a FPC -> MIC -> PIC scenario: > > * We could either let the user specify the template variable name on the module, so the user could enter `fpc` for the FPC, `mic` for the MIC and `pic` for the pic. Then the templated interface on the PIC could be `xe-{fpc}/{mic}/{pic}` where we just follow the parent relationship until we reach the root module, gathering the template names and the positions. > * Another way would be to add an index to template variable, so maybe the root would remain {module} and subsequent nested modules would be {module-2}, {module-3}, {module-4} etc. > * A third way would be to just used {module} for all nesting levels but replace them from left to right. This is more limiting but probably easier to implement. > > Another thing that needs to be decided is how to make it clear that module bays on a module template applies to the module and will not be instantiated on the device like the other device components. Maybe it's not an issue, but it might be more clear to find another name or figure out another way to present it in the UI instead of under `Add components`. I don't believe unlimited nesting would be good for anyone. But we must also consider that if we say 1 level is ok, but 2 or 3 or 4 levels isn't .. inevitably someone is going to say "why can't I go 2 or 3 levels deep, my hardware works like that" If we were to perhaps strike a balance of allowing maybe 2 layers deep? I have not seen any equipment in my years that has a module that goes into a module that goes into a module that goes into a module :D The Cisco ASR 9K for example has power supplies that go into a Power Module .. that power module then goes into the Chassis. Can anyone offer examples where you would need 3 levels deep?
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@roadracer96 commented on GitHub (Oct 4, 2022):

Isn't unlimited nesting already allowed in other places? Like regions?

I'd argue for that to future proof it if possible. It only takes one
vendor doing something differently to make it a requirement. Think of it
in terms of logical vs physical. Say, a nested bridge port extender
scenario..

On Tue, Oct 4, 2022, 11:10 AM cyr0nk0r @.***> wrote:

I have looked at this in the past, and am still considering implementing
it as we use Juniper devices like the ones in your example.

I think there's a couple of things that needs to be decided:

Are we to support unlimited nesting and how are we templating the
position? If we are to support unlimited nesting, we need to figure out how
to do the templating. Imagine a FPC -> MIC -> PIC scenario:

  • We could either let the user specify the template variable name on
    the module, so the user could enter fpc for the FPC, mic for the MIC
    and pic for the pic. Then the templated interface on the PIC could be
    xe-{fpc}/{mic}/{pic} where we just follow the parent relationship
    until we reach the root module, gathering the template names and the
    positions.
  • Another way would be to add an index to template variable, so maybe
    the root would remain {module} and subsequent nested modules would be
    {module-2}, {module-3}, {module-4} etc.
  • A third way would be to just used {module} for all nesting levels
    but replace them from left to right. This is more limiting but probably
    easier to implement.

Another thing that needs to be decided is how to make it clear that module
bays on a module template applies to the module and will not be
instantiated on the device like the other device components. Maybe it's not
an issue, but it might be more clear to find another name or figure out
another way to present it in the UI instead of under Add components.

I don't believe unlimited nesting would be good for anyone. But we must
also consider that if we say 1 level is ok, but 2 or 3 or 4 levels isn't ..
inevitably someone is going to say "why can't I go 2 or 3 levels deep, my
hardware works like that"

If we were to perhaps strike a balance of allowing maybe 2 layers deep? I
have not seen any equipment in my years that has a module that goes into a
module that goes into a module that goes into a module :D

The Cisco ASR 9K for example has power supplies that go into a Power
Module .. that power module then goes into the Chassis. Can anyone offer
examples where you would need 3 levels deep?

—
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/10500#issuecomment-1267158351,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCMTM2LEO6WCR7HWIG6DMDWBRCIFANCNFSM6AAAAAAQX5B3C4
.
You are receiving this because you authored the thread.Message ID:
@.***>

@roadracer96 commented on GitHub (Oct 4, 2022): Isn't unlimited nesting already allowed in other places? Like regions? I'd argue for that to future proof it if possible. It only takes one vendor doing something differently to make it a requirement. Think of it in terms of logical vs physical. Say, a nested bridge port extender scenario.. On Tue, Oct 4, 2022, 11:10 AM cyr0nk0r ***@***.***> wrote: > I have looked at this in the past, and am still considering implementing > it as we use Juniper devices like the ones in your example. > > I think there's a couple of things that needs to be decided: > > Are we to support unlimited nesting and how are we templating the > position? If we are to support unlimited nesting, we need to figure out how > to do the templating. Imagine a FPC -> MIC -> PIC scenario: > > - We could either let the user specify the template variable name on > the module, so the user could enter fpc for the FPC, mic for the MIC > and pic for the pic. Then the templated interface on the PIC could be > xe-{fpc}/{mic}/{pic} where we just follow the parent relationship > until we reach the root module, gathering the template names and the > positions. > - Another way would be to add an index to template variable, so maybe > the root would remain {module} and subsequent nested modules would be > {module-2}, {module-3}, {module-4} etc. > - A third way would be to just used {module} for all nesting levels > but replace them from left to right. This is more limiting but probably > easier to implement. > > Another thing that needs to be decided is how to make it clear that module > bays on a module template applies to the module and will not be > instantiated on the device like the other device components. Maybe it's not > an issue, but it might be more clear to find another name or figure out > another way to present it in the UI instead of under Add components. > > I don't believe unlimited nesting would be good for anyone. But we must > also consider that if we say 1 level is ok, but 2 or 3 or 4 levels isn't .. > inevitably someone is going to say "why can't I go 2 or 3 levels deep, my > hardware works like that" > > If we were to perhaps strike a balance of allowing maybe 2 layers deep? I > have not seen any equipment in my years that has a module that goes into a > module that goes into a module that goes into a module :D > > The Cisco ASR 9K for example has power supplies that go into a Power > Module .. that power module then goes into the Chassis. Can anyone offer > examples where you would need 3 levels deep? > > — > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/10500#issuecomment-1267158351>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCMTM2LEO6WCR7HWIG6DMDWBRCIFANCNFSM6AAAAAAQX5B3C4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Oct 4, 2022):

Isn't unlimited nesting already allowed in other places? Like regions?

I don't see any actual downside to allowing unlimited nesting if we figure out a good way for the templating. Operations traversing the relationship back to the root will obviously take longer, but it shouldn't be an issue with normal non-extreme usecases.

In some cases, allowing a limited degree of math in the calculation of interface #s would be needed.

Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless.

@kkthxbye-code commented on GitHub (Oct 4, 2022): > Isn't unlimited nesting already allowed in other places? Like regions? I don't see any actual downside to allowing unlimited nesting if we figure out a good way for the templating. Operations traversing the relationship back to the root will obviously take longer, but it shouldn't be an issue with normal non-extreme usecases. > In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless.
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 4, 2022):

Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless.

I think it is more along the lines of the {module} replacement string, however I could see instead having nested bays position being {module}-###

So if you had:

FPC0 - Line card module
-- MIC0 - Sub-module
-- -- PIC0 - Sub-Sub-module

The PIC0 "position" would be:

0/0/0

On an interface you would end up with:

0/0/0/#

@DanSheps commented on GitHub (Oct 4, 2022): > Could you please expand on this? I am fairly certain that this is not something we will entertain, but I would like to understand the usecase regardless. I think it is more along the lines of the {module} replacement string, however I could see instead having nested bays position being {module}-### So if you had: FPC0 - Line card module -- MIC0 - Sub-module -- -- PIC0 - Sub-Sub-module The PIC0 "position" would be: 0/0/0 On an interface you would end up with: 0/0/0/#
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@roadracer96 commented on GitHub (Nov 17, 2022):

Sorry about the delay.. Lots of demands on my time right now.

Right now, we allow a single variable in defining interface names in the
form of { module }.

In a nested module scenario, wed need a way to account for sub-modules. In
a juniper device, the MIC creates an offset in the PICs.

Example:
A 20x1g MIC has 2 PICs
The MIC goes into an FPC that has 2 slots. MIC0 and MIC1
If you put the MIC in MIC0, it has PIC0 and PIC1 resulting in ge-0/0/[0-9]
and ge-0/1/[0-9]
If you put the MIC in MIC1, the ports are ge-0/2/[0-9] and ge-0/3/[0-9]

Real world example:
FPC 0 REV 26 750-031089 CAAZ7366 MPC Type 2 3D
CPU REV 08 711-030884 CAAZ7050 MPC PMB 2G
MIC 0 REV 28 750-028387 ABCA5555 3D 4x 10GE XFP
PIC 0 BUILTIN BUILTIN 2x 10GE XFP
Xcvr 0 NON-JNPR F8084039010B XFP-10G-SR
Xcvr 1 REV 01 740-014289 M1009743 XFP-10G-SR
PIC 1 BUILTIN BUILTIN 2x 10GE XFP
Xcvr 0 NON-JNPR W443937701B4 XFP-10G-SR
Xcvr 1 NON-JNPR C737XS0DU XFP-10G-SR
MIC 1 REV 24 750-028392 ABBL7092 3D 20x 1GE(LAN) SFP
PIC 2 BUILTIN BUILTIN 10x 1GE(LAN) SFP
PIC 3 BUILTIN BUILTIN 10x 1GE(LAN) SFP
Xcvr 0 REV 02 740-013111 M0608300101 SFP-T
Xcvr 1 REV 02 740-013111 M0608300047 SFP-T
Xcvr 2 REV 01 740-011784 M07C1200184 SFP-EX
Xcvr 3 REV 01 740-011784 M07C1200194 SFP-EX

So maybe there are 2 asks:

  1. Add {module-n} functionality where n is the degree of nesting.
    module-0 would represent the top level card, module-1 the next level and
    so-on. This would work for a lot of future use case I could see.
  2. Basic math functions in deriving the interface number

The template format may end up looking like this:

ge-{module-0}/{module-12+0}/[0-9] <-- PIC0
ge-{module-0}/{module-12+1}/[0-9] <-- PIC1

Assuming FPC1 {module-0} with MICs 0/1 {module-1} both populated:

ge-1/02+0/[0-9] = ge-1/0/[0-9] <- FPC 1 MIC 0 PIC 0
ge-1/02+1/[0-9] = ge-1/1/[0-9] <- FPC 1 MIC 0 PIC 1
and
ge-1/12+0/[0-9] = ge-1/2/[0-9] <- FPC 1 MIC 1 PIC 2
ge-1/12+1/[0-9] = ge-1/3/[0-9] <- FPC 1 MIC 1 PIC 3

This shouldnt tax the system as it is really only used int he templating
process and not every time you click on a device..

Thoughts?

On Tue, Oct 4, 2022 at 1:52 PM kkthxbye @.***> wrote:

Isn't unlimited nesting already allowed in other places? Like regions?

I don't see any actual downside to allowing unlimited nesting if we figure
out a good way for the templating. Operations traversing the relationship
back to the root will obviously take longer, but it shouldn't be an issue
with normal non-extreme usecases.

In some cases, allowing a limited degree of math in the calculation of
interface #s would be needed.

Could you please expand on this? I am fairly certain that this is not
something we will entertain, but I would like to understand the usecase
regardless.

—
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/10500#issuecomment-1267353758,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCMTMZVHWF6426TJFZUD3DWBRVFBANCNFSM6AAAAAAQX5B3C4
.
You are receiving this because you authored the thread.Message ID:
@.***>

@roadracer96 commented on GitHub (Nov 17, 2022): Sorry about the delay.. Lots of demands on my time right now. Right now, we allow a single variable in defining interface names in the form of { module }. In a nested module scenario, wed need a way to account for sub-modules. In a juniper device, the MIC creates an offset in the PICs. Example: A 20x1g MIC has 2 PICs The MIC goes into an FPC that has 2 slots. MIC0 and MIC1 If you put the MIC in MIC0, it has PIC0 and PIC1 resulting in ge-0/0/[0-9] and ge-0/1/[0-9] If you put the MIC in MIC1, the ports are ge-0/2/[0-9] and ge-0/3/[0-9] Real world example: FPC 0 REV 26 750-031089 CAAZ7366 MPC Type 2 3D CPU REV 08 711-030884 CAAZ7050 MPC PMB 2G MIC 0 REV 28 750-028387 ABCA5555 3D 4x 10GE XFP PIC 0 BUILTIN BUILTIN 2x 10GE XFP Xcvr 0 NON-JNPR F8084039010B XFP-10G-SR Xcvr 1 REV 01 740-014289 M1009743 XFP-10G-SR PIC 1 BUILTIN BUILTIN 2x 10GE XFP Xcvr 0 NON-JNPR W443937701B4 XFP-10G-SR Xcvr 1 NON-JNPR C737XS0DU XFP-10G-SR MIC 1 REV 24 750-028392 ABBL7092 3D 20x 1GE(LAN) SFP PIC 2 BUILTIN BUILTIN 10x 1GE(LAN) SFP PIC 3 BUILTIN BUILTIN 10x 1GE(LAN) SFP Xcvr 0 REV 02 740-013111 M0608300101 SFP-T Xcvr 1 REV 02 740-013111 M0608300047 SFP-T Xcvr 2 REV 01 740-011784 M07C1200184 SFP-EX Xcvr 3 REV 01 740-011784 M07C1200194 SFP-EX So maybe there are 2 asks: 1. Add {module-n} functionality where n is the degree of nesting. module-0 would represent the top level card, module-1 the next level and so-on. This would work for a lot of future use case I could see. 2. Basic math functions in deriving the interface number The template format may end up looking like this: ge-{module-0}/{module-1*2+0}/[0-9] <-- PIC0 ge-{module-0}/{module-1*2+1}/[0-9] <-- PIC1 Assuming FPC1 {module-0} with MICs 0/1 {module-1} both populated: ge-1/0*2+0/[0-9] = ge-1/0/[0-9] <- FPC 1 MIC 0 PIC 0 ge-1/0*2+1/[0-9] = ge-1/1/[0-9] <- FPC 1 MIC 0 PIC 1 and ge-1/1*2+0/[0-9] = ge-1/2/[0-9] <- FPC 1 MIC 1 PIC 2 ge-1/1*2+1/[0-9] = ge-1/3/[0-9] <- FPC 1 MIC 1 PIC 3 This shouldnt tax the system as it is really only used int he templating process and not every time you click on a device.. Thoughts? On Tue, Oct 4, 2022 at 1:52 PM kkthxbye ***@***.***> wrote: > Isn't unlimited nesting already allowed in other places? Like regions? > > I don't see any actual downside to allowing unlimited nesting if we figure > out a good way for the templating. Operations traversing the relationship > back to the root will obviously take longer, but it shouldn't be an issue > with normal non-extreme usecases. > > In some cases, allowing a limited degree of math in the calculation of > interface #s would be needed. > > Could you please expand on this? I am fairly certain that this is not > something we will entertain, but I would like to understand the usecase > regardless. > > — > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/10500#issuecomment-1267353758>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCMTMZVHWF6426TJFZUD3DWBRVFBANCNFSM6AAAAAAQX5B3C4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@craized commented on GitHub (Dec 19, 2022):

Storing/presenting the module names as a list/stack seems like a pretty clean solution to me. Each sub-module could be pushed onto the module position stack which could then be shifted off in order for name completions. If a module name requires more module positions than are available, an exception is raised. If an interface name requires more module positions than are available in the stack, they are ignored/discarded.

Module 0: FPC 0         - Supports {module} in templating
|-> Module 0: MIC 0     - Supports {module}/{module} in templating
    |-> Module 0: PIC 0 - Supports {module}/{module}/{module} in templating

In the FPC/MIC/PIC scenario, an example interface of ge-{module}/{module}/{module} would only populate when a module is slotted 3 modules deep (sub-sub-module?).

@craized commented on GitHub (Dec 19, 2022): Storing/presenting the module names as a list/stack seems like a pretty clean solution to me. Each sub-module could be pushed onto the module position stack which could then be shifted off in order for name completions. If a module name requires more module positions than are available, an exception is raised. If an interface name requires more module positions than are available in the stack, they are ignored/discarded. ``` Module 0: FPC 0 - Supports {module} in templating |-> Module 0: MIC 0 - Supports {module}/{module} in templating |-> Module 0: PIC 0 - Supports {module}/{module}/{module} in templating ``` In the FPC/MIC/PIC scenario, an example interface of `ge-{module}/{module}/{module}` would only populate when a module is slotted 3 modules deep (sub-sub-module?).
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@aztec102 commented on GitHub (Jan 28, 2023):

Let me try another example with the Alcatel Lucent 7750 SR-12 router. The router has 10 useful slots. Line cards (IOMs) are inserted into these slots. Each line card is divided into two compartments, where you can already put a submodule (in Nokia terminology = MDA). Also for example, we will take MDA = m2-10gb-xp-xfp which has two XFP 10Gb ports.
Let's imagine a situation that we take IOM and put it in slot 3. get the first index 3
We put the MDA in slot 1 in this IOM.
Already got index 3/1
As a result, we get two ports in the system 3/1/1 and 3/1/2

Therefore, I fully agree with my comrades, this implementation is very necessary.

@aztec102 commented on GitHub (Jan 28, 2023): Let me try another example with the Alcatel Lucent 7750 SR-12 router. The router has 10 useful slots. Line cards (IOMs) are inserted into these slots. Each line card is divided into two compartments, where you can already put a submodule (in Nokia terminology = MDA). Also for example, we will take MDA = m2-10gb-xp-xfp which has two XFP 10Gb ports. Let's imagine a situation that we take IOM and put it in slot 3. get the first index 3 We put the MDA in slot 1 in this IOM. Already got index 3/1 As a result, we get two ports in the system 3/1/1 and 3/1/2 Therefore, I fully agree with my comrades, this implementation is very necessary.
adam commented 2025-12-29 19:48:15 +01:00
Author
Owner
Copy Link

@ppcarvalhof commented on GitHub (Apr 5, 2023):

Thought would need to be put into using the {module} variable in a nested fashion to permit automatic addition of interfaces based on the module template. In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. But from a pure inventory standpoint, having the ability to populate these the way some network devices see them would be very useful.

Really the lack of this possibility is a big limiting factor in NetBox for modular equipment. There is even something similar missing in the interface itself (for duplex/simplex modules) but, I digress...

keep in mind that netbox is not an inventory system, and you should not use modules for asset tracking.

This statement FOR ME makes no sense if we think that the idea of NetBox is to reflect the reality of how the equipment is and how they are interconnected. This for me is a very objective term when I think about documentation. The inventory, in my view, would be the aggregation of information on this equipment and cabling. Therefore, I cannot understand why it is not correct to add inventory information directly to the equipment. Just look at NetBox's own slogan: "The Premiere Network Source of Truth"

This idea has already been raised under #9107, however no detailed implementation was proposed. This issue also does not provide any substantial detail. Please flesh out your proposal to include the necessary details, especially the proposed database changes, so that they can be considered and discussed.

@jeremystretch I have a suggested implementation of a resource for modular interfaces. Could you contact him privately to help me formulate this proposition well? I know what to suger, but I don't know how. LOL

Storing/presenting the module names as a list/stack seems like a pretty clean solution to me. Each sub-module could be pushed onto the module position stack which could then be shifted off in order for name completions. If a module name requires more module positions than are available, an exception is raised. If an interface name requires more module positions than are available in the stack, they are ignored/discarded.

Module 0: FPC 0         - Supports {module} in templating
|-> Module 0: MIC 0     - Supports {module}/{module} in templating
    |-> Module 0: PIC 0 - Supports {module}/{module}/{module} in templating

In the FPC/MIC/PIC scenario, an example interface of ge-{module}/{module}/{module} would only populate when a module is slotted 3 modules deep (sub-sub-module?).

That would be more or less the way I think it would be interesting.

On how to resolve the recursion in the new feature I think that even using the {module} variable could be something "inheritable". Let's say I have a device (F) that has 4 slots (S) and in these slots we can place boards (P) and these boards allow us to place modules (let's say 4x10G qSFP Modules). I think that, when modeling, I would create something similar to the Frame/Slot/Port/M structure where the inheritance would be directly from the module, the {module} variable would already be resolved and saved as a string (processed only once). Let's say I put card X in slot 1 of the equipment (Frame 0). In the equipment model, the position in the Modulo entry would be 1 and the string would be resolved as 0/1. So what would be modeled on this board as port {module}/[1-12]. In this case, the first port the variable {module} would be saved as the string 0/1/1, the second port the string saved would be 0/1/2, etc... When inserting the module in port 1 the interface being modeled like GE {module}:[1-4]. The first interface string would be saved as GE 0/1/1:1. That is, the variable {module} would refer only to what is saved in "position" of the immediately superior bay. I think this would be the best way to resolve the "infinite" recursion of the variable without compromising the NetBox structure.

@ppcarvalhof commented on GitHub (Apr 5, 2023): > Thought would need to be put into using the {module} variable in a nested fashion to permit automatic addition of interfaces based on the module template. In some cases, allowing a limited degree of math in the calculation of interface #s would be needed. But from a pure inventory standpoint, having the ability to populate these the way some network devices see them would be very useful. Really the lack of this possibility is a big limiting factor in NetBox for modular equipment. There is even something similar missing in the interface itself (for duplex/simplex modules) but, I digress... > keep in mind that netbox is not an inventory system, and you should not use modules for asset tracking. This statement FOR ME makes no sense if we think that the idea of NetBox is to reflect the reality of how the equipment is and how they are interconnected. This for me is a very objective term when I think about documentation. The inventory, in my view, would be the aggregation of information on this equipment and cabling. Therefore, I cannot understand why it is not correct to add inventory information directly to the equipment. Just look at NetBox's own slogan: "The Premiere Network Source of Truth" > This idea has already been raised under #9107, however no detailed implementation was proposed. This issue also does not provide any substantial detail. Please flesh out your proposal to include the necessary details, especially the proposed database changes, so that they can be considered and discussed. @jeremystretch I have a suggested implementation of a resource for modular interfaces. Could you contact him privately to help me formulate this proposition well? I know what to suger, but I don't know how. LOL > Storing/presenting the module names as a list/stack seems like a pretty clean solution to me. Each sub-module could be pushed onto the module position stack which could then be shifted off in order for name completions. If a module name requires more module positions than are available, an exception is raised. If an interface name requires more module positions than are available in the stack, they are ignored/discarded. > > ``` > Module 0: FPC 0 - Supports {module} in templating > |-> Module 0: MIC 0 - Supports {module}/{module} in templating > |-> Module 0: PIC 0 - Supports {module}/{module}/{module} in templating > ``` > > In the FPC/MIC/PIC scenario, an example interface of `ge-{module}/{module}/{module}` would only populate when a module is slotted 3 modules deep (sub-sub-module?). That would be more or less the way I think it would be interesting. On how to resolve the recursion in the new feature I think that even using the {module} variable could be something "inheritable". Let's say I have a device (F) that has 4 slots (S) and in these slots we can place boards (P) and these boards allow us to place modules (let's say 4x10G qSFP Modules). I think that, when modeling, I would create something similar to the Frame/Slot/Port/M structure where the inheritance would be directly from the module, the {module} variable would already be resolved and saved as a string (processed only once). Let's say I put card X in slot 1 of the equipment (Frame 0). In the equipment model, the position in the Modulo entry would be 1 and the string would be resolved as 0/1. So what would be modeled on this board as port {module}/[1-12]. In this case, the first port the variable {module} would be saved as the string 0/1/1, the second port the string saved would be 0/1/2, etc... When inserting the module in port 1 the interface being modeled like GE {module}:[1-4]. The first interface string would be saved as GE 0/1/1:1. That is, the variable {module} would refer only to what is saved in "position" of the immediately superior bay. I think this would be the best way to resolve the "infinite" recursion of the variable without compromising the NetBox structure.
adam commented 2025-12-29 19:48:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2023):

As any implementation of nested modules would rely on a recursive nesting strategy, I'm marking this as blocked by #6587 / #11421.

@jeremystretch commented on GitHub (May 2, 2023): As any implementation of nested modules would rely on a recursive nesting strategy, I'm marking this as blocked by #6587 / #11421.
adam commented 2025-12-29 19:48:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 27, 2023):

Unblocking this as we still haven't identified a suitable replacement for MPTT

@jeremystretch commented on GitHub (Dec 27, 2023): Unblocking this as we still haven't identified a suitable replacement for MPTT
adam commented 2025-12-29 19:48:16 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Jan 28, 2024):

There is a use-case for passive optical equipment, as well. An LGX enclosure that holds LGX patch panels as modules in some cases should also be modeled to have module bays themselves, such as removable splice trays. An example would be this type of patch panel, where I would prefer to model the splice tray separately as they used in many applications. See the picture below for an illustration.

image

@eronlloyd commented on GitHub (Jan 28, 2024): There is a use-case for passive optical equipment, as well. An LGX enclosure that holds LGX patch panels as modules in some cases should also be modeled to have module bays themselves, such as removable splice trays. An example would be [this type of patch panel](https://wirewerks.com/app/uploads/PDS/PDS-0234-LGXtra-Patch-Module.pdf), where I would prefer to model the splice tray separately as they used in many applications. See the picture below for an illustration. ![image](https://github.com/netbox-community/netbox/assets/197778/d45507d0-398d-441c-97fd-4a26f94148f8)
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: high status: accepted 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#7040
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?