Allow modules to contain module bays and modules to be parents of other modules.

[roadracer96]

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

[mmfreitas]

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.

[roadracer96]

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.

[jeremystretch]

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.

[kkthxbye-code]

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.

[jeremystretch]

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

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?

[roadracer96]

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 <#10500 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCMTM2LEO6WCR7HWIG6DMDWBRCIFANCNFSM6AAAAAAQX5B3C4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kkthxbye-code]

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.

[DanSheps]

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