Extend modules with types and interface associations

[arbor-bdoyle]

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.

[arbor-bdoyle]

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!

[specialcircumstances]

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.

[jeremystretch]

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.