Change device type does not update the components under the device

[Jason Guy]

Hi all,

We are working on migrating devices to netbox. In some cases, the migration script is not able to identify the device-type. So I created a placeholder "unknown" device type. Unfortunately, when I manually verify and change the device to the correct device-type, it does not appear to inherit the components. I found I need to delete the devices, and re-add them with the correct device-type. So apparently the device components are created from the device-type at the time of device creation. Thinking about this some more, it seems like changing the device-type could automatically change the device components (delete and re-add). Just curious if this is a problem for others, and if it is a viable enhancement.

Thanks,

Jason

[Chris Smolen]

Oh please make this a thing!  Just had to go and recreate so many devices.

[Brian Candler]

On Wednesday, 3 April 2019 00:53:48 UTC+1, Jason Guy wrote:

So apparently the device components are created from the device-type at the time of device creation.

That's correct.

I definitely wouldn't want interfaces to be destroyed and created when a device type is changed.  I have the opposite situation to you: I might create a device of type "unknown", add a bunch of interfaces and configure them, and later change the device to a more specific type "foo".  I wouldn't want to see all that work destroyed.

However I did have a case where I added ports to a Device Type and wanted to see them added to all instances of that Device too.  Ideally there would be some sort of 'resync components' button which would add missing components, and update existing components with matching type and name.

What I did was to write a script, which at least creates all the missing interfaces on all devices - where "missing" is defined as "no such port exists with the given name"

import django

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'netbox.settings')

django.setup()

 

from dcim.models import Device, ConsolePort, ConsoleServerPort, PowerPort, PowerOutlet, Interface, RearPort, FrontPort, DeviceBay

 

for device in Device.objects.all():

            # Based on Device.save()

            ConsolePort.objects.bulk_create(

                [ConsolePort(device=device, name=template.name) for template in

                 device.device_type.consoleport_templates.all()

                 if template.name not in {i.name for i in device.consoleports.all()}]

            )

            ConsoleServerPort.objects.bulk_create(

                [ConsoleServerPort(device=device, name=template.name) for template in

                 device.device_type.consoleserverport_templates.all()

                 if template.name not in {i.name for i in device.consoleserverports.all()}]

            )

            PowerPort.objects.bulk_create(

                [PowerPort(device=device, name=template.name) for template in

                 device.device_type.powerport_templates.all()

                 if template.name not in {i.name for i in device.powerports.all()}]

            )

            PowerOutlet.objects.bulk_create(

                [PowerOutlet(device=device, name=template.name) for template in

                 device.device_type.poweroutlet_templates.all()

                 if template.name not in {i.name for i in device.poweroutlets.all()}]

            )

            Interface.objects.bulk_create(

                [Interface(device=device, name=template.name, form_factor=template.form_factor,

                           mgmt_only=template.mgmt_only) for template in device.device_type.interface_templates.all()

                           if template.name not in {i.name for i in device.interfaces.all()}]

            )

            RearPort.objects.bulk_create([

                RearPort(

                    device=device,

                    name=template.name,

                    type=template.type,

                    positions=template.positions

                ) for template in device.device_type.rearport_templates.all()

                  if template.name not in {i.name for i in device.rearports.all()}

            ])

            FrontPort.objects.bulk_create([

                FrontPort(

                    device=device,

                    name=template.name,

                    type=template.type,

                    rear_port=RearPort.objects.get(device=device, name=template.rear_port.name),

                    rear_port_position=template.rear_port_position,

                ) for template in device.device_type.frontport_templates.all()

                  if template.name not in {i.name for i in device.frontports.all()}

            ])

            DeviceBay.objects.bulk_create(

                [DeviceBay(device=device, name=template.name) for template in

                 device.device_type.device_bay_templates.all()

                 if template.name not in {i.name for i in device.device_bays.all()}]

            )

Regards,

Brian.

[Brian Candler]

Grr, Google Groups has mangled it.  I've now posted it to a gist instead:

https://gist.github.com/candlerb/195ecd0fcc6aca6f7218d6e312dd0ee1

[Brian Candler]

And here is a corresponding Report, which tells you if any Devices are missing components from their Device Type (but doesn't fix them)

https://gist.github.com/candlerb/c5b8774701e6d0d0f33415c7257c7d05

[Jason Guy]

Hey Brian, 

Thanks for sharing; that is a cool solution. We were thinking of fixing this and making a pull request, but I thought it would be better to ask first, in case I am missing something. I think it would be cool if the action of "change device type" would essentially create a new 'copy' of the device with the correct device-type. Then determine what aspects would get 'copied' from the old device components, into the new one. Obviously this would be a best-effort thing, and if it does not easily map, or requires more customization, it could display a remapping view. 

For example, perhaps your intern accidentally created the device using the 32-port version, and realize it is a 48 port device. Well the power, console, management interfaces, and the first 32 connections may simply be copied to the new device where the specific entities align. Obviously you could just add 16 ports to the existing device, but if this happened for a few devices, it would be annoying. :)

Cheers,

Jason

On Wed, Apr 3, 2019 at 5:42 AM Brian Candler <b.ca...@pobox.com> wrote:

And here is a corresponding Report, which tells you if any Devices are missing components from their Device Type (but doesn't fix them)

https://gist.github.com/candlerb/c5b8774701e6d0d0f33415c7257c7d05

--
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-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/102bfedc-6454-4abb-a368-3e1e76a22eee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Candler]

On Wednesday, 3 April 2019 15:29:14 UTC+1, Jason Guy wrote:

 I think it would be cool if the action of "change device type" would essentially create a new 'copy' of the device with the correct device-type. Then determine what aspects would get 'copied' from the old device components, into the new one. Obviously this would be a best-effort thing, and if it does not easily map, or requires more customization, it could display a remapping view. 

I'm not sure why you would make a copy of the device, when you'll end up deleting the original device anyway.

Instead, you could look for any interfaces which exist on the new device type, but do not exist on the current device; then you could create them automatically.  You'd probably want confirmation first.

You could also look for any interfaces which currently exist on the device, but do *not* exist on the new device type.  Almost certainly you'll want confirmation before deleting those.

Remember that this needs to be done for bulk updates as well as individual device updates.

 

For example, perhaps your intern accidentally created the device using the 32-port version, and realize it is a 48 port device. Well the power, console, management interfaces, and the first 32 connections may simply be copied to the new device where the specific entities align.

If they have the same names - otherwise you have no way of knowing they are the same.

What happens if your intern accidentally creates the device as a 48-port, when it's 32-port?  Do you want to delete the excess interfaces?

 

Obviously you could just add 16 ports to the existing device, but if this happened for a few devices, it would be annoying. :)

Hence the script I posted - which could be modified to apply to a single device.  And it could be incorporated in the UI, at the points where a device type is changed.

[Jason Guy]

Hi Brian,

I agree with you. Your script is perfect. I guess I was envisioning how the UI would work. I agree the copy is not good, but without it is hard to compare the original to the new. So yes, the easy solution is when the change is easy and would do essentially what your script does. If the change was not easy (ie 48-port->32-port), I was thinking the user would need to provide guidance via the UI. In that case, there would need to be a view to allow the user to select the remapping, deleting, etc. Anyhow, I am just thinking about the interactive part... :)

Jason

--

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-discus...@googlegroups.com.
To post to this group, send email to netbox-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/d49b5b12-cef6-4aca-ab58-0ad307d8d214%40googlegroups.com.

[Brian Candler]

And I should have said: if the device is actually 48-port, but your intern accidentally changes it to 32-port, then deleting the "excess" interfaces risks major loss of data - all the connected cables, all the IP addresses, all the MAC addresses.

The same could happen if you change from one device type to another, but the two different devices have different naming schemes for their interfaces.

Another problem: sometimes you *must* change the names of devices to be different from their canonical device type names.  This happens when using the Virtual Chassis feature.  For example, you may have two devices with interfaces Gi1/0/1-1/0/24, but you need to rename all the interfaces on the second device to Gi2/0/1-2/0/24 before you join them together into a virtual chassis.  If you intentionally or accidentally change the device type of the second one, and change it back, you may end up with spurious additional interfaces.