Extensions to device bay behavior

[bdo...@arbor.net]

Hi all,

We've been experimenting with Netbox as a replacement for our current equipment database, and it's looking very promising. The devices in our lab present some interesting situations that we're still debating how best to handle, so I thought I would raise them here to see if any of our proposed changes are things that you would be interested in pulling upstream. I'll start with the small one. Feel free to break them apart if some seem doable and others do not. :)

The first addition we would like to make is to add an index/weight field to device bays. Our boxes have blades that are intended to be installed in specific slots, so ordering them alphabetically (or with natsort) isn't ideal. Being able to select whether bays are sorted ascending or descending based on this field would be a bonus. This would be defined on the device type and editable on individual devices, like other fields.

The second is a bit (a lot) larger. We have a number of devices which are composed of blades, but for which it makes sense to treat the set of chassis + blades as the entire device. To achieve this, we would like to modify the UI to pull interfaces, (and IP addresses, etc), from the children through to the parent device detail page. This way, when boxes are modified by moving blades around, the interfaces do not have to be manually removed and redefined on the chassis, but instead belong to the blade as in reality.

We're aware that this isn't currently the intent of child devices in the Netbox model, as stated in some other threads here ("Is it possible to enter a child device without device name?"), but we think it would be a worthwhile addition and could encompass some of the other existing suggestions/issues. For example, #373 on being able to group interfaces based on line card would be solved by just having the interfaces belong to the line card.

There are other similar changes that could be made to the API, but these are not as necessary, as our automation can be made to do any sort of rearranging that is necessary to achieve the same effect.

I have been prototyping some of these changes to see how feasible it would be. It's clear that it's a fairly large change, which is why I wanted to bring it to the list now to see if this is something you are even interested in doing. The other option is of course to just treat these blades as modules and place the interfaces on the chassis, but it would be nice to be able to more closely reflect reality, and it would solve many of the scalability issues we have with our current system.

I've included a screenshot of what I've built out so far, with interfaces being categorized and pulled only from children defined as having network interfaces. I've hidden the options to modify these interfaces, instead requiring the user to visit the page for blade to change them. This reflects the essentially static nature of the blades.

Thanks for your time and all your work on this project, Netbox is already proving to be a major improvement for us.

Bill Doyle

QA Engineer

Arbor Networks

[Jeremy Stretch]

Hi Bill,

First off, thank you for your interest in NetBox and for such a detailed explanation!

Your first idea (manually assigning weights to device bay slots) is pretty trivial to implement, as you expect. The second point touches on some weaknesses of how device modules are modeled in NetBox's current form.

It sounds like you have a good idea of how device bays and modules are intended to function, but I'll provide some additional context for less familiar readers. The difference between the two essentially boils down to treatment of the control plane. Device bays are meant to house independently-managed devices that rely on a host merely for physical installation and perhaps power (a chassis of micro servers, for example). In contrast, modules are meant to represent physical components which are fully managed by the parent device's control plane (for example, line cards installed in a chassis switch).

If I understand correctly, your use case pertains to the second application, although I understand why you're drawn to using device bays. The current representation of modules in NetBox was implemented primarily as an inventory function: NetBox has a limited (and undocumented) ability to poll inventory data from live devices (e.g. `show chassis hardware` on Juniper gear) and create modules in its database to represent each piece of hardware. This works well if all you care about is tracking serial numbers, but lacks the robustness needed for intelligent management of chassis blades.

> The other option is of course to just treat these blades as modules and place the interfaces on the chassis, but it would be nice to be able to more closely reflect reality, and it would solve many of the scalability issues we have with our current system.

I think this would be the ideal solution. We could create a ModuleType object to parallel the function of DeviceType; instances of a ModuleType would take the form of Modules installed within a Device. We could extend the Interface model so that each interface may optionally be associated with a module in addition to a device. (I'd still like to retain the direct association with devices in the interest of performance.) We would also need to introduce the concept of ModuleBays to house modules, which would parallel the function of DeviceBays.

I'm sure I'm glossing over some intricacies but I think this would be perfectly workable. The biggest hurdle might be adopting the existing modules implementation to work with the new scheme, but I'm sure we can handle that with a migration or twelve.

Let me think on this for a bit more and I'll see what I come up with. Feel free to open a GitHub issue for this request if you'd like, or I can open one after I've got a proposed scheme more fleshed out.

Thanks again,

Jeremy

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/eb827985-ac02-4a88-a561-9ee45cee21ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bdo...@arbor.net]

Hi Jeremy,

Excellent news! I will get an issue opened and use it as a place to write up some of the open concerns I've already run into. Can't wait to see what you come up with.

It seems someone else beat me to an issue for the same thing just now (#823), shall I add on to that, or start a new one specifically for implementing it using modules?

Bill

To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.

[Jeremy Stretch]

Let's start a fresh issue, and I'll link #823 to it. Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/355b786e-0659-4e2a-84b9-f0cf55c90c80%40googlegroups.com.