[] Feature request
[X] Bug report
[ ] Documentation
From the device page, there's only the option to add a new IP address. From the IP address edit page, the "Interface Assignment" section is hidden. There is actually a workaround if you manually modify the IP address edit URL to include ?interface=x. If it isn't desirable to have the Interface Assignment section show up on every IP Address edit screen, it'd be nice to have a button on the Device page next to the current "New IP" one.
Related: #786, #1001, group thread
That thread says:
As interfaces can now be assigned to both devices and virtual machines, it becomes very difficult to specify interfaces without additional context. For instance, when creating an IP, you can assign it to an interface by searching for a device, by selecting a device (from a series of dropdowns), by searching for a virtual machine, or by selecting a virtual machine. It becomes very tedious and confusing to include all of these widgets in a single form.
Another option would be to allow linking an existing IP address to an interface, rather than vice versa. It might work like this:
Alternate flow:
[^1] If the address is already linked to another interface this should be indicated in the results table, but you can still take it over.
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.
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.
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
Both linked cases are closed. One should stay open until resolution correct?
I think this is also a bug and not a feature request.
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
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.
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?
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.
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.
袗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"
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.
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.
Just to be clear, you add this to the URL when you are editing the IP address. Example:
/ipam/ip-addresses/9/edit//ipam/ip-addresses/9/edit/?interface=33 in the URL barAnd 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.
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.
Can we change this to a bug as this was available in a previous version?
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.
Yup, It has only been removed since the VM support was added.
Sweet! Testing now. Thank you @jeremystretch!
Works for me. Cheers!
Awesome, thanks!
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 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
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.
Still minor issue but created new issue #1718
Most helpful comment
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