Assign existing IP Address to Device Interface #1246

@candlerb commented on GitHub (Sep 20, 2017):

Just to be clear: the UI no longer appears to offer any way to assign an existing IP address object to an interface.

You have to delete the address, and recreate it when you add to an interface. This is inconvenient because it means all the information relating to that address has to be re-entered (Status, Role, Description, Tenancy etc); furthermore, the Address changes its API ID, and the Django history of changes to that object is lost.

A specific use case is when migrating from a flat IPAM spreadsheet to Netbox. Starting from a flat model you likely will import all the IP addresses first, and then later decide to create devices/vms/interfaces to attach them to.

@candlerb commented on GitHub (Sep 20, 2017): Just to be clear: the UI no longer appears to offer any way to assign an *existing* IP address object to an interface. You have to delete the address, and recreate it when you add to an interface. This is inconvenient because it means all the information relating to that address has to be re-entered (Status, Role, Description, Tenancy etc); furthermore, the Address changes its API ID, and the Django history of changes to that object is lost. A specific use case is when migrating from a flat IPAM spreadsheet to Netbox. Starting from a flat model you likely will import all the IP addresses first, and then later decide to create devices/vms/interfaces to attach them to.

adam commented

@awerner commented on GitHub (Sep 27, 2017):

We're currently experiencing the use case @candlerb mentioned, using ?interface=X is a workaround, but it would be nice to have a way to do this without needing to resort manipulating the URL.

It would be also a nice workflow being able to select a free IP in the IPAM and then assing it to an interface when creating the IP address.

@awerner commented on GitHub (Sep 27, 2017): We're currently experiencing the use case @candlerb mentioned, using ?interface=X is a workaround, but it would be nice to have a way to do this without needing to resort manipulating the URL. It would be also a nice workflow being able to select a free IP in the IPAM and then assing it to an interface when creating the IP address.

adam commented

@phurrelmann commented on GitHub (Oct 2, 2017):

Additionally it is no longer possible to move an ip-address from one device to another without deleting and re-adding the ip-address.
IMHO this is not an enhancement but an regression, as functionality is lost

@phurrelmann commented on GitHub (Oct 2, 2017): Additionally it is no longer possible to move an ip-address from one device to another without deleting and re-adding the ip-address. IMHO this is not an enhancement but an regression, as functionality is lost

adam commented

@dirtycajunrice commented on GitHub (Oct 16, 2017):

Both linked cases are closed. One should stay open until resolution correct?

@dirtycajunrice commented on GitHub (Oct 16, 2017): Both linked cases are closed. One should stay open until resolution correct?

adam commented

@InsaneSplash commented on GitHub (Oct 17, 2017):

I think this is also a bug and not a feature request.

@InsaneSplash commented on GitHub (Oct 17, 2017): I think this is also a bug and not a feature request.

adam commented

@explody commented on GitHub (Oct 27, 2017):

I'll chime in and add that this really is a critical feature. I completely sympathize about the potential for an excessively cluttered dialog in attempting to associated interface/VM-interface back and forth to an IP. But, I would be willing to take slight clutter to (re)gain this feature.

The ability to cleanly find, (pre)create and associate IPs-to-interfaces and interfaces-to-IPs is well worth the complication IMHO. (I can give gory details on our live use cases if it's interesting)

@candlerb's ideas are minimal and the first is transparent, which is great. Here's another that involves user input but also provides good feedback to the user when creating or reassigning IPs

Add a prefix selector dropdown on the add-ip-address form, constrained to the prefixes associated with the device's site, perhaps grouped by VRF. This selector can be optional, and the IP field can still accept freeform IP/mask input. This has a side effect of allowing IP-in-prefix validation, at least on the user side, if a prefix is selected.
If a prefix is selected, the Address input field could have a widget akin to https://github.com/djk2/django-popup-view-field (which can render existing views and could be useful elsewhere as well), which would allow for selecting an existing IP. Constraining this to only when a prefix is selected dodges around an excessively large contents inside the widget. It also could give an opportunity for users to see free IPs inside a prefix, for selection rather than manual entry.

Since it's comparatively easy to reassign or even recreate IPs via the API, this mostly distills down to a UI/UX issue, IMHO. Honestly, not my strong suit but I do know the current UX is is very difficult for my engineers ;)

I'd be happy to help work on this.

@explody commented on GitHub (Oct 27, 2017): I'll chime in and add that this really is a critical feature. I completely sympathize about the potential for an excessively cluttered dialog in attempting to associated interface/VM-interface back and forth to an IP. But, I would be willing to take slight clutter to (re)gain this feature. The ability to cleanly find, (pre)create and associate IPs-to-interfaces and interfaces-to-IPs is well worth the complication IMHO. (I can give gory details on our live use cases if it's interesting) @candlerb's ideas are minimal and the first is transparent, which is great. Here's another that involves user input but also provides good feedback to the user when creating or reassigning IPs * Add a prefix selector dropdown on the add-ip-address form, constrained to the prefixes associated with the device's site, perhaps grouped by VRF. This selector can be optional, and the IP field can still accept freeform IP/mask input. This has a side effect of allowing IP-in-prefix validation, at least on the user side, if a prefix is selected. * If a prefix is selected, the Address input field could have a widget akin to https://github.com/djk2/django-popup-view-field (which can render existing views and could be useful elsewhere as well), which would allow for selecting an existing IP. Constraining this to only when a prefix is selected dodges around an excessively large contents inside the widget. It also could give an opportunity for users to see _free_ IPs inside a prefix, for selection rather than manual entry. Since it's comparatively easy to reassign or even recreate IPs via the API, this mostly distills down to a UI/UX issue, IMHO. Honestly, not my strong suit but I do know the current UX is is very difficult for my engineers ;) I'd be happy to help work on this.

adam commented

@francoisbeaulieu commented on GitHub (Oct 31, 2017):

Pardon my naïveté, but wouldn't the simplest solution be to redefine the VMs as a subcategory of devices, (say, by adding a column VM, which defaults to 'no', in the devices table) which would allow to populate the form's drop-down with only devices?

@francoisbeaulieu commented on GitHub (Oct 31, 2017): Pardon my naïveté, but wouldn't the simplest solution be to redefine the VMs as a subcategory of devices, (say, by adding a column VM, which defaults to 'no', in the devices table) which would allow to populate the form's drop-down with only devices?

adam commented

@candlerb commented on GitHub (Nov 1, 2017):

Devices and VMs already share the same Interface object.

The issue being discussed here is: (1) being able to assign an existing IP address to an interface; and (2) being able to move an existing IP address from one interface to another interface on a different device or VM.

Certainly, if you approach this from the IP Address side, you'd have to identify the interface to attach it to. This could be done simply by a search on the name, showing all Devices and VMs that the search matches. That's more convenient anyway than drilling down via Site -> Rack -> Device, or Cluster -> VM.

If you've already navigated to a particular Device->Interface or VM->Interface, then you just want to search for a particular IP address to attach to it.

@candlerb commented on GitHub (Nov 1, 2017): Devices and VMs already share the same Interface object. The issue being discussed here is: (1) being able to assign an existing IP address to an interface; and (2) being able to move an existing IP address from one interface to another interface on a different device or VM. Certainly, if you approach this from the IP Address side, you'd have to identify the interface to attach it to. This could be done simply by a search on the name, showing all Devices and VMs that the search matches. That's more convenient anyway than drilling down via Site -> Rack -> Device, or Cluster -> VM. If you've already navigated to a particular Device->Interface or VM->Interface, then you just want to search for a particular IP address to attach to it.

adam commented

@ckupe commented on GitHub (Nov 3, 2017):

Adding my +1 to this issue. Was about to report this myself.

Before there was VM support, we had added "FQDN" and "Port Translation" custom fields to our IP objects. We also resorted to putting machine names in the Description so we could find their IPs.

When I started trying to connect all of the pre-existing IPs with these VMs, I discovered the fact that assignment of the IP is impossible from either end. Can't connect it by editing the IP, or can't connect it when creating the interface on the VM and trying to assign the IP.

I can see how this interaction is easily overlooked, but it has halted documentation. Without a way to at least bulk-import these interface creation+assignments or a way to link these objects, it's too tedious to delete and recreate IPs.

@ckupe commented on GitHub (Nov 3, 2017): Adding my +1 to this issue. Was about to report this myself. Before there was VM support, we had added "FQDN" and "Port Translation" custom fields to our IP objects. We also resorted to putting machine names in the Description so we could find their IPs. When I started trying to connect all of the pre-existing IPs with these VMs, I discovered the fact that assignment of the IP is impossible from either end. Can't connect it by editing the IP, or can't connect it when creating the interface on the VM and trying to assign the IP. I can see how this interaction is easily overlooked, but it has halted documentation. Without a way to at least bulk-import these interface creation+assignments or a way to link these objects, it's too tedious to delete and recreate IPs.

adam commented

@GitRost commented on GitHub (Nov 3, 2017):

Аnd me, you can also add to this issue.
Created in advance a lot of the right ip addresses and then was unpleasant surprised trying to assign them devices and ports!
I had to use a crutch "? interface = x"

@GitRost commented on GitHub (Nov 3, 2017): Аnd me, you can also add to this issue. Created in advance a lot of the right ip addresses and then was unpleasant surprised trying to assign them devices and ports! I had to use a crutch "? interface = x"

adam commented

@sylaan commented on GitHub (Nov 6, 2017):

I am also affected by this. We have first migrated all our IPs into Netbox and then, as we add devices, we assign IPs to various interfaces. This is no longer possible since the last update.

I don't really understand why #1639 is marked as a duplicate of this and closed. It seems to me it's a severe loss of functionality. If the assigning of an IP to a device interface is supposed to be done now by editing the device, then this issue should be a bug since that's not possible.

@sylaan commented on GitHub (Nov 6, 2017): I am also affected by this. We have first migrated all our IPs into Netbox and then, as we add devices, we assign IPs to various interfaces. This is no longer possible since the last update. I don't really understand why #1639 is marked as a duplicate of this and closed. It seems to me it's a severe loss of functionality. If the assigning of an IP to a device interface is supposed to be done now by editing the device, then this issue should be a bug since that's not possible.

adam commented

@ckupe commented on GitHub (Nov 6, 2017):

Until they fix this, the workaround is to append '?interface=###' to the URL where ### is the interface number referencing the device interface you need to connect. The options will appear.

This is still incredibly tedious though. I might just create a script button that hooks into the browser or a hack-job extension to do this in the meantime.

@ckupe commented on GitHub (Nov 6, 2017): Until they fix this, the workaround is to append '?interface=###' to the URL where ### is the interface number referencing the device interface you need to connect. The options will appear. This is still incredibly tedious though. I might just create a script button that hooks into the browser or a hack-job extension to do this in the meantime.

adam commented

@candlerb commented on GitHub (Nov 6, 2017):

Just to be clear, you add this to the URL when you are editing the IP address. Example:

Navigate to /ipam/ip-addresses/9/edit/
Change this to /ipam/ip-addresses/9/edit/?interface=33 in the URL bar
Hit Enter to redraw the page. The correct interface should now be shown.
Click Save

And to find it's interface 33, you first need to navigate to the device or VM in question, and click the edit button (pencil) next to the interface.

@candlerb commented on GitHub (Nov 6, 2017): Just to be clear, you add this to the URL when you are editing the IP address. Example: * Navigate to `/ipam/ip-addresses/9/edit/` * Change this to `/ipam/ip-addresses/9/edit/?interface=33` in the URL bar * Hit Enter to redraw the page. The correct interface should now be shown. * Click Save And to find it's interface 33, you first need to navigate to the device or VM in question, and click the edit button (pencil) next to the interface.

adam commented

@sylaan commented on GitHub (Nov 6, 2017):

Yes, I am familiar with the workaround and I am using it. It works but it's extremely inconvenient, as already mentioned. I hope this will be solved soon. I am just very surprised this is treated as a feature request and not a bug.

@sylaan commented on GitHub (Nov 6, 2017): Yes, I am familiar with the workaround and I am using it. It works but it's extremely inconvenient, as already mentioned. I hope this will be solved soon. I am just very surprised this is treated as a feature request and not a bug.

adam commented

@InsaneSplash commented on GitHub (Nov 8, 2017):

Can we change this to a bug as this was available in a previous version?

@InsaneSplash commented on GitHub (Nov 8, 2017): Can we change this to a bug as this was available in a previous version?

adam commented

@KWI-TFenby commented on GitHub (Nov 8, 2017):

We only just started using netbox, so I didn't even realize when reporting this that it was a regression, which it definitely is if this was possible in previous versions. This issue is the reason we've had to put our implementation on hold.

@KWI-TFenby commented on GitHub (Nov 8, 2017): We only just started using netbox, so I didn't even realize when reporting this that it was a regression, which it definitely is if this was possible in previous versions. This issue is the reason we've had to put our implementation on hold.

adam commented

@InsaneSplash commented on GitHub (Nov 8, 2017):

Yup, It has only been removed since the VM support was added.

@InsaneSplash commented on GitHub (Nov 8, 2017): Yup, It has only been removed since the VM support was added.

adam commented

@KWI-TFenby commented on GitHub (Nov 10, 2017):

Sweet! Testing now. Thank you @jeremystretch!

@KWI-TFenby commented on GitHub (Nov 10, 2017): Sweet! Testing now. Thank you @jeremystretch!

adam commented

@candlerb commented on GitHub (Nov 10, 2017):

Works for me. Cheers!

@candlerb commented on GitHub (Nov 10, 2017): Works for me. Cheers!

adam commented

@sylaan commented on GitHub (Nov 11, 2017):

Awesome, thanks!

@sylaan commented on GitHub (Nov 11, 2017): Awesome, thanks!

adam commented

@InsaneSplash commented on GitHub (Nov 15, 2017):

I upgraded to 2.2.5 and when I edit an IP address that is not linked to an interface it still does not provide the option to select a device/interface unless I use the work around of appending ?interface= to the URL?

@InsaneSplash commented on GitHub (Nov 15, 2017): I upgraded to 2.2.5 and when I edit an IP address that is not linked to an interface it still does not provide the option to select a device/interface unless I use the work around of appending ?interface= to the URL?

adam commented

@dirtycajunrice commented on GitHub (Nov 15, 2017):

@insanesplash it is now another tab. You will see the "add an IP address" vs find one at the top of the page after you click the green plus

@dirtycajunrice commented on GitHub (Nov 15, 2017): @insanesplash it is now another tab. You will see the "add an IP address" vs find one at the top of the page after you click the green plus

adam commented

@candlerb commented on GitHub (Nov 15, 2017):

That is: you can't do it directly from the IP address. Instead, you have to navigate to the device or VM where you want to attach the IP, then click the green plus next to the interface you want to attach it to, then use the tab as @DirtyCajunRice says.

@candlerb commented on GitHub (Nov 15, 2017): That is: you can't do it directly from the IP address. Instead, you have to navigate to the device or VM where you want to attach the IP, then click the green plus next to the interface you want to attach it to, then use the tab as @DirtyCajunRice says.

adam commented