3.2-Beta: DCIM Module Ideas

[iunderwood]

I've had some time to start working with the modular feature that was introduced in 3.2 beta, and I've got to say that this is going to shape up to be a pretty awesome feature.

However, there are a few things worth note:

If the module interfaces are generally created, but they have been created by other means, it will throw up an integrity error:

`<class 'django.db.utils.IntegrityError'>

duplicate key value violates unique constraint "dcim_interface_device_id_name_bffc4ec4_uniq"
DETAIL: Key (device_id, name)=(2348, GigabitEthernet5/0/1) already exists.

Python version: 3.8.10
NetBox version: 3.2.0-beta2`

For example, "GigabitEthernet5/0/1" exists, but the module is templated "GigabitEthernet{module}/0/1"

I figure a more verbose error explanation can be put up in the event some interface already exist and the add resources is not viable.

The module works, if the components are not replicated. Of course, the interfaces that exist are not associated to the module.

If a module gets deleted, interfaces associated with that module also get removed. The problem I see here is that we have a full-on delete which will undo any cables that were done on the old linecard. I expect this is going to catch some people by surprise the first time they attempt a card upgrade and find it blows out a number of documented connections.

It might be prudent to allow for interfaces associated with the card to be preserved upon deletion (could be a checkbox), or not allow the operation if any of the interfaces being deleted have a connection. "Cannot delete resources that are connected." or something to that verbiage.

Just spitballing on a Saturday ...

[jeremystretch]

If the module interfaces are generally created, but they have been created by other means, it will throw up an integrity error:

If you can provide steps for reproducing this, please open a bug report for it.

If a module gets deleted, interfaces associated with that module also get removed.

Yep, that's intentional; just as in the real world, if you remove a module, its interface go away too.

The problem I see here is that we have a full-on delete which will undo any cables that were done on the old linecard.

This does not represent a change from existing behavior: Deleting an interface, for example, will also remove any attached cable.

It might be prudent to allow for interfaces associated with the card to be preserved upon deletion (could be a checkbox)

Would be worth a feature request, at least.

[iunderwood]

Thanks for the feedback!

I will put in a bug report shortly for the behavior I have seen, probably over the weekend.

It's good to know the module removal behavior is intentional. However, the consideration i have comes with field upgrades where a line card is replaced with something similar. For instance, removing a 48-port 1G card, and putting in something that is a similar config, like a 48-port line card, but has 24 1G, 24 10G, and POE support. In most migrations i have worked through, the new card goes where the old one went and the ports are rewired 1:1.

Pretty much, I want to keep my junior network staff from replacing a card and finding out they blew out all the cable records. This is where I think a warning pop-up may be prudent.

Then again, it might be a better idea for me to write a script to properly handle a card swap.