Community approach to the new modules model.

[ryanmerolle]

A number of people have been submitting PRs on the devicetype-library repo that look to add new devices with modules or update existing device definitions.

I have noticed people are trying to use modules for more than just a network device module like a line card, supervisor card, HWIC, etc.

I have seen this go so far as to be applied to PCIE slots & swappable Power Supplies as modules.

The NetBox core team does not really have an opinion on the approach, but we would want to get user input on what we think the standard that should be applied to the devicetype-library repo should be.
The reason modules model was added to NetBox was for primary benefit of modules is being able to automatically populate many components at once, which isn't typically a concern with single-port PSUs
.

Depending on the feedback here, we can discuss the same for PCIE slots in servers.

[minitriga]

I believe anything that goes into a "Chassis" should be a module. For example the type of power supply installed into some switch determines its POE capability and being able to track them separately is pretty important in large environments.

[ekrichbaum]

My $0.02...

Module Bay (as implemented) and Device Bay (as implemented) have different use cases and are useful. I can see extension to modules to allow for sub-modules even at the smaller device level (NM module goes into a router and has 2 HWIC slots for modules that have interfaces). That being said, I also see a reason for device bays. Depending on a device, a bay may be an AFO or AFI fan, an AFO or AFI power supply. I view these as different than modules but can see that naming or use case can be unclear. I personally use device bays for server blades, power supplies, fans and the like, module bays for I/o modules, line cards with interfaces, and the like.

Potentially, this can be addressed in documentation, but, the wonderful thing here is that once you set up Netbox, you can choose to do it your own way.

[ryanmerolle]

device-bays are really more for discrete nodes in a device like controllers or blade servers to be clear.

[ekrichbaum]

I left controllers as modules as well though because of the interfaces/console ports involved.

[ryanmerolle]

For devices like Pure , Netapp, Rubrik, and other storage controllers, I always set them into device-bays since they are managed as their own nodes. They also often get managed as a cluster, but the chassis itself has no System Board.

[DanSheps]

Using device bays for components (fans, port supplies, etc) is a incorrect use, you should be using modules or inventory items for that.

[m2martin]

I use module bays for everything that adds additional types of connections to the device.
A PSU adds power ports. As many devices support different types of PSUs, which can have different types of connectors (e.g. AC/DC) or provide different power, this can be all modeled by using modules.
For everything else that is "just in the chassis" but has no influence to any type of connections (e.g. fan modules) I use inventory items.

[ekrichbaum]

I can see that on power supplies I guess, so could be swayed for sure.

[jeremystretch]

Some thoughts in no particular order:

• Defining a PSU as a module requires the separate definition of a module type for instantiation. This may or may not be desirable.
• Defining a PSU as a module is objectively a more accurate representation of the real world (for devices with removable PSUs).
• A device type definition would be limited to defining module bays: It would not include power supplies or power ports. Those would be defined in the separate module type definition, and the user would need to "install" those modules after creating the device.

I think I'm leaning toward modeling removable PSUs as modules in the device type library, primarily because it is more accurate to do so. Users will of course retain the flexibility to alter these definitions and forgo the module-based approach if they so choose.

[m2martin]

As a result of all the posts, opinions and use cases, I'd suggest to write kind of "modeling best practice" with some examples per type, once we agree on how the different kinds of "modularization" should be treated and used.
The different approaches are terribly interesting...

[ryanmerolle]

That is the post of this discussion. To see where people land so we can prescribe a best practice to adhere to and document in the devicetype repo.

[jcralbino]

Normally introducing a PSU would include the addition of a power plug to be added to the model also.

I would associate additional psu as a module as o would do for a line card

[iunderwood]

There is one point of concern that I think we need to address before we do more with the modules in the repo.

I believe we should add a field to both the module bays and the module types, perhaps something like "module key". This field would be to limit module selection to things that have a matching key.

For instance, I have a Cisco 9407 with line card modules, supervisor modules, and power supply modules. With a key (e.g. "C9400-SUP") I would only select modules that have a matching key.

I can flesh out the idea a bit more and submit it for consideration.

[ekrichbaum]

a module type type and corresponding module bay type. This doesn't address the case that some slots would be multifunction, i.e. a SUP slot that could house a line card instead of a second SUP.

[iunderwood]

It could be done so a module bay supports multiple keys.

[DanSheps]

My view (because I just removed a bunch of incorrectly defined console ports/console server ports). The main problem I saw was with servers so...

For servers:

• USB = Not defined unless it provides a power, console, console server, or network function using only that port, a regular USB port does not do that out of the box. A console server with a console server port == GOOD. iDRAC/iLO USB ports should be modelled as network ports, as that is how they operate . rPI's are powered by USB sometimes, so that can be modelled as a power port.
• VGA/DVI/HDMI/etc = console port if you truely need to model this
• PSU = Module bay with a corresponding module type defined appropriately elsewhere
• PCI/etc = Module bay because you can place NICs, etc in there
• Removeable Fans = Inventory item, if you want to go ham, you could model as a module but I think that is a huge task so I would tread carefully
• Hard disks = Inventory item

Blade servers (Cisco UCS, Dell whatever, etc) seem to use device bays appropriately.

[ITJamie]

going to throw a small spanner in the works here which would require some netbox adjustments
How about being able to define the "default module" as part of these.
for example in a lot of dells newer servers the network slot by default module is a set of 4x 1gb ports.
It would be nice for that data to be in the default template so that when you create a device you get a sane set of "defaults" so to spea, for psu's and server nics this would be useful.
otherwise adding a new device now by default becomes a multistep affair whereas before it was "correct" most of the time.

Im aware i could just hardcode these options like previously. but then you lose the advantage of being able to "swap" a module to the correct one for the non-standard usecases

[ryanmerolle]

module-bays do confuse me with the modeling a little since it would make power port sections unneeded for swappable PSUs.

[DanSheps]

I don't follow

[ryanmerolle]

Thankfully you do not follow. I have not delved myself much into modules. Most of my infra are fixed form 1 us chassis.

Call this a mental breakdown or a test. If you did follow I would be concerned @DanSheps :)

[mtinberg]

I think what they are saying is that previous to Module Bays one would model power supplies as Power Ports directly on the Device Type, same as for the default set of Interfaces, and then change them only if necessary after creating a new Device, but with Modules it seems "more correct" to not model Power Ports on the Device Types record but instead create Module Bays for all the swappable components and add them separately after the Device record is created, but this takes a process where you can create a Device that is mostly correct in one step, and only need to do added work it if it is in a non-default configuration, into a guaranteed multi-step process where you have to populate the uplink module, power supplies, etc. separately and immediately after creating a Device even if you have a common configuration. One could use Scripts or something to automate this process, or continue modeling devices in the old style, at least for Device Types where the added flexibility and "correctness" of using Module Bays for the FRU components isn't helpful. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Daniel Sheppard ***@***.***> Sent: Saturday, May 28, 2022 5:29 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Community approach to the new modules model. (Discussion #9238) I don't follow — Reply to this email directly, view it on GitHub<#9238 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM57ALTJL7MRIYHT45TVMKM4VANCNFSM5UPAIV7A>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[shatt79]

I'd still like to see nested modules. Some line cards contain multiple slots for child cards/SPAs/MPAs. Also, defining an interface type as simply "SFP" or "SFP+" (etc) isn't very intuitive because there are dozens of variations of each transceiver form-factor. With SFP+, I can have duplex 10, 20, 40, 60, 80, 120km versions. I can have bi-di variants of the same distances. I can have CWDM and DWDM versions, tunable DWDM, etc. MFGs of these are even more numerous. Knowing exactly what type of transceiver is installed in a given port is necessary for inventory and sparing purposes. If I have to dispatch a tech due to a perceived transceiver failure, I'd like to be able to send him out to the site with the appropriate spare.

Modular power supplies should always be modules. There are AC and DC versions of almost all of them, in varying wattages. Again, necessary for tracking of inventory and sparing.

[mtinberg]

I would suggest that CWDM/DWDM/Bidi/output-power is not a property of the interface you plug it into which is a standard SFP/SFP+/QSFP/etc. but of the optic you put in it, adding custom fields on the Interface to store more data about the specific optic might make more sense for tracking this data One other consideration is that every field and feature added to the core data model is potential administrivia for every instance to handle, even if it's just to create audit reports and forbidding people from using fields they don't have the resources to maintain, whereas custom fields and plugins only incur cost to the instances which use them. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: shatt79 ***@***.***> Sent: Tuesday, May 31, 2022 3:03 PM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Community approach to the new modules model. (Discussion #9238) I'd still like to see nested modules. Some line cards contain multiple slots for child cards/SPAs/MPAs. Also, defining an interface type as simply "SFP" or "SFP+" (etc) isn't very intuitive because there are dozens of variations of each transceiver form-factor. With SFP+, I can have duplex 10, 20, 40, 60, 80, 120km versions. I can have bi-di variants of the same distances. I can have CWDM and DWDM versions, tunable DWDM, etc. MFGs of these are even more numerous. Knowing exactly what type of transceiver is installed in a given port is necessary for inventory and sparing purposes. If I have to dispatch a tech due to a perceived transceiver failure, I'd like to be able to send him out to the site with the appropriate spare. Modular power supplies should always be modules. There are AC and DC versions of almost all of them, in varying wattages. Again, necessary for tracking of inventory and sparing. — Reply to this email directly, view it on GitHub<#9238 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2MZHY3DC6STN6SJB3VMZWAZANCNFSM5UPAIV7A>. You are receiving this because you commented.Message ID: ***@***.***>