Extend modules with types and interface associations #648

Originally created by @arbor-bdoyle on GitHub (Jan 20, 2017).

As discussed on the mailing list, it would be desirable to extend the functionality of modules to more closely reflect reality when it comes to systems composed of blades.

I originally prototyped it by repurposing device bays, but the modules approach seems much cleaner. It also has the benefit of being nearly a blank slate to work with. Here are some of the issues that apply to either approach which will need to be worked out:

Interface naming + device type interface formats
- In most chassis based switches and similar devices, the name of an interface depends on the slot that the blade is in. If adding and removing a module is going to automatically add/remove interfaces, the names will have to be dynamically generated based on the slot and also the naming scheme for that particular device type.
- If a module is moved to a different slot, do we automatically rename the interfaces? I'm picturing a sort of unnamed interface that is dealt with automatically, but then names could be overridden so they are never changed automatically (the current behavior).
- Can/should this be tied to the latent ability to query the device for information?
Handling module removal
- If interfaces are still going to be primarily associated with the chassis, removing a module has a couple options: delete them again, destroying connection information, or somehow mark them as disabled. We could possibly reuse the existing 'planned' connection for this?
- Should adding a module back to the same slot then automatically reconnect all of the appropriate interfaces if they already exist on the chassis?
- Should interfaces be outright deleted if they are not connected?
Module bay ordering/naming
- Similar to the mention on the mailing list of adding a weight to device bays, module bays should also be able to be weighted so that they can be ordered as in real life if blades are intended to be installed in a certain order.
- Because module bays will be reflecting the actual behavior of the device, it would be useful to be able to query this from the API as well. Perhaps it should be named something other than 'weight'. (Or we could defer that to proper naming of the bays.)
- Ascending/descending sort for this should be defined on device types, so that weight can correspond to the physical numbering of slots and avoid being confusing.
Creation of new modules
- I'm assuming that this will be done entirely from the module page as opposed to creating them on the rack first like with child devices.
- Ideally modules will no longer have to be named if they are going into a pre-defined module bay, because the purpose of the bay defines what the module is from the perspective of the containing device. Having a bay named 'line card 1' is the same information as having a module with that name. Names could still be overridden, though.
- Do we still want to allow extra modules to be created that do not go into a predefined bay?

That's all I've got for now. Looking forward to fleshing this out.

Originally created by @arbor-bdoyle on GitHub (Jan 20, 2017). As discussed [on the mailing list](https://groups.google.com/forum/#!topic/netbox-discuss/nZDfO3AWnGc), it would be desirable to extend the functionality of modules to more closely reflect reality when it comes to systems composed of blades. I originally prototyped it by repurposing device bays, but the modules approach seems much cleaner. It also has the benefit of being nearly a blank slate to work with. Here are some of the issues that apply to either approach which will need to be worked out: - Interface naming + device type interface formats - In most chassis based switches and similar devices, the name of an interface depends on the slot that the blade is in. If adding and removing a module is going to automatically add/remove interfaces, the names will have to be dynamically generated based on the slot and also the naming scheme for that particular device type. - If a module is moved to a different slot, do we automatically rename the interfaces? I'm picturing a sort of unnamed interface that is dealt with automatically, but then names could be overridden so they are never changed automatically (the current behavior). - Can/should this be tied to the latent ability to query the device for information? - Handling module removal - If interfaces are still going to be primarily associated with the chassis, removing a module has a couple options: delete them again, destroying connection information, or somehow mark them as disabled. We could possibly reuse the existing 'planned' connection for this? - Should adding a module back to the same slot then automatically reconnect all of the appropriate interfaces if they already exist on the chassis? - Should interfaces be outright deleted if they are not connected? - Module bay ordering/naming - Similar to the mention on the mailing list of adding a weight to device bays, module bays should also be able to be weighted so that they can be ordered as in real life if blades are intended to be installed in a certain order. - Because module bays will be reflecting the actual behavior of the device, it would be useful to be able to query this from the API as well. Perhaps it should be named something other than 'weight'. (Or we could defer that to proper naming of the bays.) - Ascending/descending sort for this should be defined on device types, so that weight can correspond to the physical numbering of slots and avoid being confusing. - Creation of new modules - I'm assuming that this will be done entirely from the module page as opposed to creating them on the rack first like with child devices. - Ideally modules will no longer have to be named if they are going into a pre-defined module bay, because the purpose of the bay defines what the module is from the perspective of the containing device. Having a bay named 'line card 1' is the same information as having a module with that name. Names could still be overridden, though. - Do we still want to allow extra modules to be created that do not go into a predefined bay? That's all I've got for now. Looking forward to fleshing this out.

adam added the type: feature pending closure status: under review labels 2025-12-29 16:24:17 +01:00

adam closed this issue

adam commented

@arbor-bdoyle commented on GitHub (Feb 14, 2017):

Hi again! I just wanted to check in on the status of this. We're getting to the point where we want to start pulling from Netbox with some of our automation, so we want to move forward with the use of modules if that is in fact the right thing to do. We can live with entering things manually for now as long as they're ending up in the right places for later on.

We're happy to contribute code if you have more pressing issues to work on right now, just want to make sure we take it in the right direction!

@arbor-bdoyle commented on GitHub (Feb 14, 2017): Hi again! I just wanted to check in on the status of this. We're getting to the point where we want to start pulling from Netbox with some of our automation, so we want to move forward with the use of modules if that is in fact the right thing to do. We can live with entering things manually for now as long as they're ending up in the right places for later on. We're happy to contribute code if you have more pressing issues to work on right now, just want to make sure we take it in the right direction!

adam commented

@specialcircumstances commented on GitHub (Feb 14, 2017):

This sounds useful, especially for chassis based / modular network devices (et al).
It might be useful to consider carefully how IO modules and internal busses might usefully fit into this.

@specialcircumstances commented on GitHub (Feb 14, 2017): This sounds useful, especially for chassis based / modular network devices (et al). It might be useful to consider carefully how IO modules and internal busses might usefully fit into this.

adam commented

@jeremystretch commented on GitHub (Mar 21, 2017):

Quick update: I've renamed Module to InventoryItem for version 2.0. This will leave space for a new Module model to support this feature.

@jeremystretch commented on GitHub (Mar 21, 2017): Quick update: I've renamed Module to InventoryItem for version 2.0. This will leave space for a new Module model to support this feature.

adam commented

@cmacnevin commented on GitHub (Nov 7, 2018):

Is this earmarked for an upcoming release? We're trying to integrate Netbox into an environment entirely dependent on modular chassis, and can't quite get there without something like this.
Cheers.

@cmacnevin commented on GitHub (Nov 7, 2018): Is this earmarked for an upcoming release? We're trying to integrate Netbox into an environment entirely dependent on modular chassis, and can't quite get there without something like this. Cheers.

adam commented

@berahtlv commented on GitHub (Nov 18, 2018):

For chassis based switches or routers Parent device can show Child devices interface list without any change of Interface names, that is done at the moment with Virtual Chassis, when Master shows list of all interfaces (own + members) and each member show only its interfaces.

Additionally to that 'Device Bay Name/Virtual Chassis position' column for Interfaces table can be added in Device View to visually differ bindings to Bay/Member if interface names are identical.

@berahtlv commented on GitHub (Nov 18, 2018): For chassis based switches or routers Parent device can show Child devices interface list without any change of Interface names, that is done at the moment with Virtual Chassis, when Master shows list of all interfaces (own + members) and each member show only its interfaces. Additionally to that 'Device Bay Name/Virtual Chassis position' column for Interfaces table can be added in Device View to visually differ bindings to Bay/Member if interface names are identical.

adam commented

@DanSheps commented on GitHub (May 25, 2020):

As this is roadmapped for 2.10, I figured I should chime in here. For the data model, I think it would make sense to allow multiple parent switches, as there are certain modules which are not attached to a specific switch (an example would be the Nexus 2000 fabric extenders) but for all intents and purposes are modules themselves.

Not sure how feasible this is, but I think it is much better then using the virtual chassis approach (as in the nexus 2k senario, the two chassis aren't combined except for in the case of the FEX). The only problem is how to actually model this, as I am assuming the "module" approach Jeremy is thinking with this is similar to device bays (it would be the approach I would take as well) but perhaps it might be possible to do a hybrid where you can attach them to slots or "virtual slots" and in virtual slots they can be racked elsewhere whereas if they are a physical slot, they are slotted into a bay.

@DanSheps commented on GitHub (May 25, 2020): As this is roadmapped for 2.10, I figured I should chime in here. For the data model, I think it would make sense to allow multiple parent switches, as there are certain modules which are not attached to a specific switch (an example would be the Nexus 2000 fabric extenders) but for all intents and purposes are modules themselves. Not sure how feasible this is, but I think it is much better then using the virtual chassis approach (as in the nexus 2k senario, the two chassis aren't combined except for in the case of the FEX). The only problem is how to actually model this, as I am assuming the "module" approach Jeremy is thinking with this is similar to device bays (it would be the approach I would take as well) but perhaps it might be possible to do a hybrid where you can attach them to slots or "virtual slots" and in virtual slots they can be racked elsewhere whereas if they are a physical slot, they are slotted into a bay.

adam commented

@pgiblock commented on GitHub (Jun 23, 2020):

I'll throw some additional complexity into the mix. That is: switch stacks. The same concept as a modular, in that the members all share the same data plane. Similarly, there are the same interface naming/numbering semantics as described in the original comment. However, this clearly doesn't fit the physical notion of a device containing the module, as the "modules" themselves in this case are actual devices and there isn't a parent. Also, Stack members are frequently in different racks (stack of TORS). Furthermore, say we have a stack of Cisco 3850s, each one may contain an actual uplink module.

I'm only bringing attention to this because there may be a chance to implement this feature request in a more generic fashion. An application of the same model to VirtualChassis essentially. Seems worth determining if something like this could be in scope before getting too deep in the design phase.

Without this, there are some difficulties. I need multiple DeviceTypes in order to model a stack. I.e: One with Gi1/0/1, Gi1/02, ... another with Gi2/0/1, Gi2/0/2, ... etc. Determining the actual management and console interfaces for a member requires clicking through all the members. IP addressing belongs to the stack, etc.

@pgiblock commented on GitHub (Jun 23, 2020): I'll throw some additional complexity into the mix. That is: switch stacks. The same concept as a modular, in that the members all share the same data plane. Similarly, there are the same interface naming/numbering semantics as described in the original comment. However, this clearly doesn't fit the physical notion of a device *containing* the module, as the "modules" themselves in this case are actual devices and there isn't a parent. Also, Stack members are frequently in different racks (stack of TORS). Furthermore, say we have a stack of Cisco 3850s, each one may contain an *actual* uplink module. I'm only bringing attention to this because there may be a chance to implement this feature request in a more generic fashion. An application of the same model to VirtualChassis essentially. Seems worth determining if something like this could be in scope before getting too deep in the design phase. Without this, there are some difficulties. I need multiple DeviceTypes in order to model a stack. I.e: One with Gi1/0/1, Gi1/02, ... another with Gi2/0/1, Gi2/0/2, ... etc. Determining the actual management and console interfaces for a member requires clicking through all the members. IP addressing belongs to the stack, etc.

adam commented

@jeremystretch commented on GitHub (Oct 13, 2020):

Punting on this for v2.10. Given the concerns noted above, we should really come up with a firm proposal before tagging this for a milestone. The primary question seems to be whether it would be feasible and appropriate to employ InventoryItem for this purpose, or to introduce an entirely new model to track the associations.

@jeremystretch commented on GitHub (Oct 13, 2020): Punting on this for v2.10. Given the concerns noted above, we should really come up with a firm proposal before tagging this for a milestone. The primary question seems to be whether it would be feasible and appropriate to employ InventoryItem for this purpose, or to introduce an entirely new model to track the associations.

adam commented

@jeremystretch commented on GitHub (Dec 22, 2020):

This issue should be considered in conjunction with #3333, as there seems to be potential for overlap.

@jeremystretch commented on GitHub (Dec 22, 2020): This issue should be considered in conjunction with #3333, as there seems to be potential for overlap.

adam commented

@stale[bot] commented on GitHub (Feb 6, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Feb 6, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@stale[bot] commented on GitHub (Mar 5, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Mar 5, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

adam commented