Modifying device types after instantiated

[llamafilm]

I've noticed that it is possible to modify a device type while there are existing instances of it. This causes some strange behavior.

Some device properties are "inherited", meaning they change automatically when the model is modified. This includes height, weight, and child status. Other device properties (including airflow, interfaces, and power ports) can be modified separately from the model.

As an example, I have a 0U child contained in a device bay. Then I modify the child's model (device type) to remove its child status and make it 1U. Now the existing child device shows a height of 1U even though it is contained in a device bay, which should not be possible!

At this point I can create a new instance of that model and install in a rack with position and face.

Now when I try to modify the model again to make it a 0U child, it fails with error:

I'm not sure how this ought to be handled, but the inconsistency bugs me.

[candlerb]

Some attributes are properties of the device type and are never copied to the device itself. These include height, weight, child status, front and rear images.

A few attributes are copied from the device type to the device when it is instantiated, and can be changed on the device independently of the device type. The only ones I can think of are "airflow" and "platform" (the latter copied from "default_platform" on the device type). This allows you to change a device from front-to-back to back-to-front airflow without having create a whole new device type.

However, linked objects (components) such as interfaces, power ports, device bays and module bays are always cloned from the device type templates (Device Type has Interface Template, Power Port Template, Device Bay Template, Module Bay Template etc). This is partly because you can add interfaces to a device after it has been created (especially virtual ones), and partly because interfaces have their own properties (e.g. MAC address), but mainly I think it's because of how Netbox's relational data model works, where cables must terminate on a specific instance of a component, and therefore each component on a device must have its own unique ID.

In principle, I agree it would be nice if all the physical ports of a device were mastered on the Device Type, because in reality if you have an instance of a particular device type, you don't drill holes in the front panel to add new ports. But that's just not how Netbox's data model is built. Making the Device Type the master would have other problems: what happens if you were to remove an interface from the Device Type, but that interface is already connected or configured in a Device instance? Also, it's possible that the same interface in the same device type has different names in different instances (e.g. because you're running a different OS, or in a different stack position). Netbox mixes the concepts of physical port (e.g. "port 1") with logical interface named by the OS (e.g. "GigabitEthernet1/0/1").

Sometimes though you realise that you are missing some components on a Device Type, and you'd like to add them and then replicate them onto existing Device instances. There are a couple of reports/scripts which can help:

• https://github.com/netbox-community/customizations/blob/master/reports/dcim-reports/missing_device_type_components.py
• https://github.com/netbox-community/customizations/blob/master/scripts/add_device_type_components.py

As for your specific problem when you change the device type of an existing device from being directly rack mounted to being mounted inside another device as a child device: that means you modelled it wrongly in the first place. I think it might be possible to fix this by first changing the existing device instance to "unracked" (it can be associated with a site, but no rack or rack position). If that doesn't work, then you may have to delete the device instance, change the device type, and then recreate the device.

[llamafilm]

Those scripts looks nice, thanks for sharing. I’ve already had some situations where that would come in handy, when I forgot something while quickly creating a device type.

You’re right, in my example I can work around by unracking the device.

I think child status is the one that bugs me the most - I have several 1/2 rack devices that are sometimes a child. Sometimes they are installed alone in a rack space, or you can flip the bracket around to mount two of them side by side. So in Netbox, I make the device a child, and adding a “mounting bracket” device as the parent. This way the rack elevation color coding doesn’t work well; it’s colored by the mounting bracket’s role. So I was thinking it would be cool if I could change the child status per instance. Oh well, color coding isn’t that big a deal.